OS SRG mappings -- items unclear/impractical

Kevin Spargur kspargur at redhat.com
Tue Jul 24 15:07:03 UTC 2012


Comments in-line

On 07/23/2012 04:58 PM, Shawn Wells wrote:
> 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?
>
Bacula is part of the server packages and could be leveraged here to 
meet this requirement.  That said, it's certainly possible to meet this 
requirement with lower level tools available on the system as Shawn 
points out.

>
>
>> 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).
I agree with Shawn that journaled file systems seem to be what is sought 
here but we should also take care to note that this CCI does not specify 
filesystems specifically and in the supplemental guidance from NIST 
(going back to CP-10) points out transactional databases as an example.  
We need to keep that in mind for services.  If NFS remains the concern 
perhaps the answer is to recommend GFS in its place.

>
>
>> 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
The language of the CCI here is convoluted.  I found the supplemental 
guidance from 800-53 to be very helpful in determining the intent of 
this check:

Enhancement Supplemental Guidance: This control enhancement is 
implemented within the
remote device (e.g., notebook/laptop computer) via configuration 
settings that are not
configurable by the user of that device. An example of a non-remote 
communications path
from a remote device is a virtual private network. When a non-remote 
connection is
established using a virtual private network, the configuration settings 
prevent split-tunneling.
Split tunneling might otherwise be used by remote users to communicate 
with the information
system as an extension of that system and to communicate with local 
resources such as a
printer or file server. Since the remote device, when connected by a 
non-remote connection,
becomes an extension of the information system, allowing dual 
communications paths such as
split-tunneling would be, in effect, allowing unauthorized external 
connections into the
system.

Shawn's approach seems like the best way to address this.

>
>
>>
>> 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?
If a sys admin turns it off intentionally I wouldn't consider that a 
failure of the boundary protection device but maybe a misconfiguration 
in /etc/sysconfig/iptables leading to the service failing to start on 
reboot is a more valid example.  I would argue that this case of 
misconfiguration leading to a failure to start is met in the guide 
already at 2.5.7.1 of the guide already 
(http://people.redhat.com/swells/scap-security-guide/RHEL6/output/rhel6-guide.html#item-iptables_activation). 
A kernel panic should meet the other cases here in a similar fashion to 
the already identified panic on a full logging volume.

>
>
>> 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?
>
>
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/scap-security-guide


More information about the scap-security-guide mailing list