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