OS SRG mappings -- items unclear/impractical

Shawn Wells shawn at redhat.com
Tue Jul 24 21:09:58 UTC 2012


On 7/24/12 11:07 AM, Kevin Spargur wrote:
> 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
Patch applied.
https://fedorahosted.org/scap-security-guide/changeset/31e4e53ee859df380f82aaec2d16d2a6825b7b52


>>> 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
Patch applied.
https://fedorahosted.org/scap-security-guide/changeset/fe976c2e8126ffe8e0404a5aadc2723791029fd4


>>> 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
Patch applied.
https://fedorahosted.org/scap-security-guide/changeset/fe976c2e8126ffe8e0404a5aadc2723791029fd4


>>> 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.
This is a great point. More investigation into Bacula is needed (at 
least for me, anyway).

>>> 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
Patched.
https://fedorahosted.org/scap-security-guide/changeset/0ef26d49f9028ae10bd2d22a4ac2eb4a5b5b089f


>>> 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
Patched.
https://fedorahosted.org/scap-security-guide/changeset/03722061eba8a24ab73946acf15241869abdd137


>>> 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