The Machine Platform Great Controversy
by Matej Tyc
Hello everybody,
there are now numerous PRs upstream now that disable the machine platform
designation of certain rules - see
https://github.com/ComplianceAsCode/content/pulls?q=is%3Apr+is%3Aopen+pla...
Historically, this project uses one profile that is intended to scan both
running systems and container images. Obviously, scanning of lifeless
filesystems (a.k.a offline scanning) is limited, and the machine platform
has been used to control rule applicability to such environments (i.e.
environments other than running bare-metal systems or VMs).
This way is cheap, a bit dirty, and the following categories of rules ended
up being machine-only:
1. Rules that are not applicable in containers, or rules that represent
serious antipatterns (e.g. kernel-related rules, partition-related rules)
2. Rules that can't be checked for in offline scans due to OVAL
limitations (anything that requires the /proc filesystem)
3. Rules that represent a likely antipattern (systemd in containers)
4. Rules that OpenSCAP can't properly offline-scan.
It is quite clear that in case No. 4, removal of the machine platform is
the right thing to do, although it is likely to cause problems elsewhere.
However, it is at best questionable in case 3. For example, there is a way
to determine whether we are scanning a filesystem of a systemd-powered
container, and execute the check accordingly, but until all the bits are in
place, removing the platform from the rule will make the situation worse
for the majority of use cases.
Therefore, I suggest that we reach a consensus about what to do with those
PRs, as they are making the list of open PRs difficult to navigate in.
My proposal is to close all PRs that touch rules falling into categories
1-3, as those PRs don't make the situation any better.
4 years, 1 month
Checks for removable partitions mount options
by Jan Cerny
Hi,
We started to work on Bugzilla [1] about a problem in rules that check
mount options for removable partitions. Currently, there are rules
mount_option_noexec_removable_partitions,
mount_option_nosuid_removable_partitions,
mount_option_nodev_removable_partitions. These rules are templated.
They use template mount_option_removable_partitions.
Overall, we have a confusion in these rules and their implementation.
The checks doesn’t appear to properly recognize when partitions are
configured with the proper nodev, nosuid, and noexec options.
Most importantly, we have found a discrepancy between the rule
description in rule.yml files of the aforementioned rules and the
actual OVAL checks used in the template (in
/shared/templates/template_OVAL_mount_option_removable_partitions).
The rule description of rule mount_option_noexec_removable_partitions
says that it prevents “direct execution of binaries from removable
media (such as a USB key)”. Also, the rationale of this rule says:
“Allowing users to execute binaries from removable media such as USB
keys exposes the system to potential compromise.” The rule description
of rule mount_option_nosuid_removable_partitions mentions removable
media in general and doesn’t specify what is considered a removable
media. On the other hand, the rule description of rule
mount_option_nodev_removable_partitions says that legitimate character
and block devices should exist only in the /dev directory on the root
partition or within chroot jails built for system services. It’s
interesting that all three rules share the same OVAL check from the
template which differ only in the mount option parameter even though
the rules contain different wording in XCCDF.
However, the OVAL check used by the template
mount_option_removable_partitions tests only /dev/cdrom. The path is
specified by XCCDF Value var_removable_partition, found in
/linux_os/guide/system/permissions/partitions/var_removable_partition.var.
This XCCDF Value has a single selector with value /dev/cdrom. Users
can change this value in their tailoring files to check for a
different block device, because But they can change this still only to
a single path. Using this path is not in line in the rule
descriptions. Obviously, using only /dev/cdrom doesn’t include USB
keys that are used as an example in
mount_option_noexec_removable_partitions. Also, it doesn’t cover
removable media in general, because there can be other types of
devices that we can imagine they’re removable. For example floppy
disks, SATA disks or SD cards.
If we know the fact that the rules use /dev/cdrom we are confused by
the OVAL check that checks multiple times if /dev/cdrom is equal to
one of: /dev/cdrom, /dev/dvd, /dev/scd0, /dev/sr0. See
constant_variable of id="variable_cd_dvd_drive_alternative_names_{{{
MOUNTOPTION }}}". This is normally true if the XCCDF Value
var_removable_partition isn’t overridden by tailoring. This comparison
is performed there multiple times. Also, the OVAL criteria tree
contains branches that are effective when this isn’t true. We imagine
that this might be some precaution for tailoring, but the use case
isn’t clear at this moment. We welcome any information that would
clear this up.
The aforementioned problem with the single block device isn’t the only
problem of these rules, we have discovered multiple other issues.
The test scenario dvd_bad_opts.fail.sh for rule
mount_option_noexec_removable_partitions is failing because scanner
returns pass instead of expected result fail. The reason is the OVAL
checks if path specified by var_removable_partition exists and if it
doesn't exist the rule fail. As we already mentioned, this variable is
always set to /dev/cdrom in all profiles, as the variable definition
has only this value. But the test scenario doesn’t create /dev/cdrom,
but /dev/dvd. Therefore, the check finds that /dev/cdrom doesn’t
exist, and the rule passes trivially.
The test scenario dvd_good_opts.pass.sh (also for rule
mount_option_noexec_removable_partitions) is broken as well. It
returns the expected result, pass, but that’s again the trivial case.
The test scenario creates /dev/dvd file at the beginning instead of
/dev/cdrom. The OVAL check passed because /dev/cdrom didn't exist.
Therefore the test scenario was not testing the actual regular
expression matching in /etc/fstab.
A more serious problem than the faulty test scenarios is that the Bash
and Ansible remediations in this template aren't functional. The
remediation code works with a mount point which is in the second
column of /etc/fstab. But they are passed values of the block device
as a parameter which is in the first column of /etc/fstab. Actually,
in all 3 rules we passed the device path (/dev/cdrom) as a mount point
instead of block device. The remediation can’t work because in this
case it looks for /dev/cdrom in the second column of /etc/fstab but it
appears in the first column. People can mount the removable media to
arbitrary directories. We think it makes sense to base the rules on
the devices instead of the mount points.
Another finding that we made is the nature of the checks. The OVAL
check isn't checking only /etc/fstab configuration, but is also
checking run-time state. That doesn’t conform to the rule
descriptions. Our understanding of the rule descriptions is that the
rules are only about configuration, there is no mention of run-time.
Moreover, after internal discussion, it’s unclear which block devices
should be considered removable in context of these rules. In theory,
multiple devices can be removable. Considering the differences in rule
descriptions we should Also, the removable device doesn't have to be
mounted at the moment of system evaluation.
If the removable device isn’t configured in /etc/fstab, then automated
mounting might happen. There are some default mount options which are
used in this situation. We don’t know where they’re defined. We think
that we should enforce presence of these entries in /etc/fstab.
However, in the past we had a Bugzilla [2] which required us to let
the rule pass if the entries aren’t mounted. If we review this
Bugzilla [2] again, we are not sure if the reporter could be fully
satisfied by the fix delivered at that time.
Some of the problems are already addressed in pull request [2].
Everyone can join the discussion. We have also added some test
scenarios there.
We think the rule is expected to check for all types of removable
devices. Probably, they could be defined as the pretty common ones,
like floppy disks, CDs, DVDs or USB sticks. But we need to clarify all
the requirements before completing the fix.
Best regards
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1691579
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1403905
[3] https://github.com/ComplianceAsCode/content/pull/5278
--
Jan Černý
Security Technologies | Red Hat, Inc.
4 years, 2 months
Off Topic: mailing list for more general hardening discussion?
by Jeff Bachtel
Could anyone point me to a mailing list more generally suited for system
hardening discussion? I have a question (What do people do about ungrouped
files created by docker?) that isn't especially topical for the SSG list.
Thanks,
--
Jeff Bachtel
Senior Cloud Ops Developer, IronNet
--
This message is intended exclusively for the individual(s) or
entity to which it is addressed. It may contain information that is
privileged or otherwise legally exempt from disclosure. If you are not the
named addressee, you are not authorized to read, print, retain, copy or
disseminate this message or any part of it. If you have received this
message in error, please notify the sender immediately by e-mail and delete
all copies of the message.
Any digital signatures or certifications
transmitted with this email are for sender verification purposes only and
have not been included in this email for the purposes of binding the
company to any statement or attachment made herein or for any other purpose.
4 years, 2 months
Questions about OSCAP for NIST Compliance checking
by David Rose
Hello. I'm brand-new to compliance because my boss wants to run compliance
on our servers. I have some questions please. I am running an OpenScap on
my CentOS 7 Linux servers, but my boss wants to get compliance against NIST
800-53 initially.
I run from OpenScap Workbench, 'US Govt Config Baseline (USGCB/STIG) -
Draft Unclassified in Non-Federal Organization(800-171)'. But when I get
the results and give them to my colleague, he says the results are only a
subset of the 800-53. So I'm not really sure what to use to ensure our
system is compliant against the full NIST 800-53..
And I don't know if I should run the compliance check from the OpenScap
Workbench and SSH to the servers or if I should run 'oscap' from the
commandline and SCP back all the output files.
And, I'm not sure if the CentOS7 or the RHEL7 variants of the scan are
really the same.
and also, when I open an .HTML formatted output file from OpenScap
Workbench, there is a 'grouping' where i can choose 800-53, but how do I
know the percentage of the listed 800-53 controls against all 800-53
controls? And which type of scan do I want to use for a full 800-53
compliance check? (Or, at least, as full as can be scanned ..)
I appreciate all constructive assistance!
-dave
4 years, 2 months