OS SRG mappings -- items unclear/impractical

Shawn Wells swells at redhat.com
Mon Jul 23 20:58:50 UTC 2012


Comments in-line below:


> 
> CCI-000024:  BIOS settings, such as enabling hardware virtualization
> and setting the BIOS password, are examples of security-relevant
> information.

Very security relevant, however is hardware configuration within scope of an operating system guide? Should there perhaps be a unique STIG for hardware platform settings?
I've heard that this has come up in the past (Jeff says Jason has mentioned it before.)

> 
> CCI-000037:  Can RHEL6 mimic Solaris RBAC functionality via SELinux?
> 

The separation is a valid requirement and there are two primary ways to implement it within RHEL.

(1) SELinux RBAC. SELinux does have the ability to produce a RBAC configuration however this would require (minimally) people convert from Targeted SELinux profiles to Strict or MLS/MCS. This would greatly increase the burden of the average SysAdmin and may not be practical outside of CNSS 12-53 systems.

(2) Fully implement sudo. This would restrict a class of users, say "AuditAdmin," to specific commands/accesses on the system without requiring full blown out SELinux. I've submitted a ticket for us to further address this in the guide (https://fedorahosted.org/scap-security-guide/ticket/69)

It remains very difficult to enforce a certain RBAC configuration across all systems, however.

> 
> CCI-000066:  Wouldn't an appropriate IPtables configuration satisfy
> this requirement?
> 

Yes. Patch created. Ticket 74 @ https://fedorahosted.org/scap-security-guide/ticket/74


> CCI-000213:  The system must require authentication upon booting into
> single-user and maintenance modes.
> 

I can see where you're going with this (if they know the password then they're approved for access). Patch created to associate this with:
http://people.redhat.com/swells/scap-security-guide/RHEL6/output/rhel6-guide.html#item-bootloader_password
http://people.redhat.com/swells/scap-security-guide/RHEL6/output/rhel6-guide.html#item-require_singleuser_auth

Ticket @ https://fedorahosted.org/scap-security-guide/ticket/75


> CCI-000213:  System BIOS or system controllers supporting password
> protection must have administrator accounts/passwords configured, and
> no others.

Same as CCI-000024. Very security relevant, however is hardware configuration within scope of an operating system guide? Should there perhaps be a unique STIG for hardware platform settings?

> 
> CCI-000213:  The system boot loader must require authentication
> against hashes computed with FIPS 140-2 approved algorithms.

Good catch. We call this out in the guide here: http://people.redhat.com/swells/scap-security-guide/RHEL6/output/rhel6-guide.html#item-bootloader_password

Will create a patch to link that section to CCI-000213. Ticket #71
https://fedorahosted.org/scap-security-guide/ticket/71


> 
> CCI-000224:  All files and directories must have a valid owner and
> group.  (Borrowed from CCI-000366)

Ticket created to generate new prose for this.
https://fedorahosted.org/scap-security-guide/ticket/76

> 
> CCI-000535, et seq.:  Does RHEL6 include any backup software, or is
> this NA-DEP?

RHEL, while including some backup capabilities, really isn't meant to be thought of us an enterprise backup solution. Because of this we mapped the requirement to out of scope for an OS.

Technically RHEL can perform a backup by:
- Using LVM snapshots
- Compressing files and moving them to another location (TAR, Zip, etc)

Willy, Jeff, we could create guidance on performing LVM snapshots and using file compression to create backups..... what do you think?



> CCI-000553:  All file systems must employ transaction-based file
> systems.
> 

Is the purpose here to ensure that a journaled file system is used?  NFS itself is technically not journaled, and RHEL otherwise uses journaled filesystems for all local drives.  What would motivate an administrator to not use a journaled filesystem, and what are the security effects?  It could be changed to "Product Meets this Requirement" given that an administrator would need significant motivation to alter the system to use a non-journaled filesystem (likely only in the face of overriding operational requirements from an unusual use case).


> CCI-001111:  The operating system must not terminate virtual private
> network (VPN) client sessions, unless it is documented as a VPN
> concentrator.

We are interpreting this requirement as remote users should not be able to VPN into a RHEL machine unless that machine is documented to be a VPN concentrator. This is the default behaviour on RHEL, so we'll map this to met_inherently. https://fedorahosted.org/scap-security-guide/ticket/80

Note that should someone want to become a VPN server we document how to do this at http://people.redhat.com/swells/scap-security-guide/RHEL6/output/rhel6-guide.html#item-install_openswan


> 
> CCI-001112:  Can RHEL6 force proxy settings on mail and web traffic?
> 

RHEL can perform routing based on ports and source/destination data. For example:

(1) Redirect outgoing connections on port 80 to another server, 192.1.1.1
iptables -A OUTPUT -t nat -p tcp --sport 80 -j DNAT --to-destination 192.1.1.1:80

RHEL doesn't make claim to be a packet inspecting firewall, so there isn't an easy way to create a rule that says "redirect all web traffic somewhere else". My concern is that if we map RHEL port redirection capability to meeting this requirement someone could simply run a webserver on a non-standard port and avoid the redirection to a proxy.

I would argue that this should stay as impractical requirement for an operating system. Such configuration is best left to applications (inside Firefox, Thunderbird, etc).


> CCI-001126:  Can RHEL6 iptables be set to default to "deny all" when
> the iptables service is stopped?  It looks like changing "set_policy
> ACCEPT" to "set_policy DROP" in /etc/init.d/iptables might do the
> trick, but that's profoundly evil.

The CCI requests that the OS fail securely when the boundary protection device fails. In the case of the OS running a local firewall we can consider iptables to be a "boundary protection device."

If a System Administrator turns off iptables, should we truly consider that a "failure" of the boundary protection device?

Also, if IPTables (as a service) does crash, it will reflect a panic in the kernel and the machine will be brought down. Perhaps we can map this to met_inherently? Jeff, Willy, thoughts?


> CCI-001352:  Get these audit records to a remote log server ASAP?
> 
Patch created to map this back to our centralized logging.
Ticket https://fedorahosted.org/scap-security-guide/ticket/81

> 
> CCI-001401:  Regarding the "binding of organization-defined security
> attributes to information in transmission", might a combination of
> non-squashed UID mapping with tight controls on which remote systems
> are allowed non-squashed NFS access cover this requirement?

I think that makes perfect sense for when using NFS, and I've created a ticket for the addition of such prose:
https://fedorahosted.org/scap-security-guide/ticket/82

This was originally mapped to impractical guidance as we did not want to create a sweeping generalization that the operating system would always be able to meet this. What if the data was being pulled out of a database -- how would the OS know what the permissions were? Arguably it's not be the OS responsibility to know such things, it should be the application performing the data exchange.


> 
> CCI-001414:  Use IPtables?
> 
Agreed. Patch to be created. Tracked via ticket:
https://fedorahosted.org/scap-security-guide/ticket/83


> 
> CCI-001668:  The system must use and update a DoD-approved virus scan
> program.

We can create a Rule with a manual (eventually OCIL) check for this. Ticket created:
https://fedorahosted.org/scap-security-guide/ticket/84


> CCI-001169, et seq.:  NA, dependent upon application (browser, etc.)
> requiring DoD-signed content.
> CCI-001239:  NA-DEP
> CCI-001291:  NA-DEP
> CCI-001555, et seq.:  NA-DEP
> CCI-001372, et seq.:  NA-DEP
> CCI-001682:  NA-DEP
> CCI-001695:  NA-DEP

If these are NA, can we get them mapped to OS-SRG-NA?




More information about the scap-security-guide mailing list