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

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

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

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

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

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

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

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

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

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

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

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.

CCI-001352: Get these audit records to a remote log server ASAP?

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?

CCI-001414: Use IPtables?

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

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

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-gu... > > http://people.redhat.com/swells/scap-security-guide/RHEL6/output/rhel6-gu... > > > 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-gu... > > 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-gu... 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-gu...). 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?