[PATCH] Check will return list of all partitions without nodev instead of a complete list of all partitions and the return value of true/false will accurately reflect passing or failing
Signed-off-by: Maura Dailey maura@eclipse.ncsc.mil --- ...mount_option_nodev_nonroot_local_partitions.xml | 28 ++++++++++--------- 1 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/RHEL6/input/checks/mount_option_nodev_nonroot_local_partitions.xml b/RHEL6/input/checks/mount_option_nodev_nonroot_local_partitions.xml index a5e6334..e0abd50 100644 --- a/RHEL6/input/checks/mount_option_nodev_nonroot_local_partitions.xml +++ b/RHEL6/input/checks/mount_option_nodev_nonroot_local_partitions.xml @@ -1,36 +1,38 @@ <def-group> - <definition class="compliance" id="mount_option_nodev_nonroot_local_partitions" version="1"> + <definition class="compliance" + id="mount_option_nodev_nonroot_local_partitions" version="1"> <metadata> <title>Add nodev Option to Non-Root Local Partitions</title> <affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected> - <description>The nodev mount option prevents files from being - interpreted as character or block devices. Legitimate character and block - devices should exist in the /dev directory on the root partition or - within chroot jails built for system services. All other locations should not - allow character and block devices.</description> + <description>The nodev mount option prevents files from being interpreted + as character or block devices. Legitimate character and block devices + should exist in the /dev directory on the root partition or within chroot + jails built for system services. All other locations should not allow + character and block devices.</description> + <reference source="MED" ref_id="20130821" ref_url="test_attestation" /> </metadata> <criteria> - <criterion comment="nodev on local filesystems" test_ref="test_nodev_nonroot_local_partitions" /> + <criterion comment="nodev on local filesystems" + test_ref="test_nodev_nonroot_local_partitions" negate="true" /> </criteria> </definition> - - <linux:partition_test check="all" check_existence="all_exist" id="test_nodev_nonroot_local_partitions" version="1" comment="nodev on local filesystems"> + <linux:partition_test check="all" check_existence="all_exist" + id="test_nodev_nonroot_local_partitions" version="1" + comment="nodev on local filesystems"> <linux:object object_ref="object_non_root_partitions" /> <linux:state state_ref="state_local_nodev" /> </linux:partition_test> - <linux:partition_object id="object_non_root_partitions" version="1"> <!-- look at all partitions except root --> <linux:mount_point operation="pattern match">^/\w.*$</linux:mount_point> <filter action="include">state_local_nodev</filter> </linux:partition_object> - <linux:partition_state id="state_local_nodev" version="1"> <!-- this check defines a local partition as one which has a device node in /dev --> <linux:device operation="pattern match">^/dev/.*$</linux:device> - <linux:mount_options datatype="string" entity_check="at least one" operation="equals">nodev</linux:mount_options> + <linux:mount_options datatype="string" entity_check="all" + operation="not equal">nodev</linux:mount_options> </linux:partition_state> - </def-group>
One quick thing I forgot to add: this will give you false positives for bind mounted partitions, as I found out when I finally tracked a phantom non-existent /home partition (underneath an NFS mount in the same location) back to the sandbox service. /proc/mounts, which is where linux:partition_test apparently reads from, doesn't know or care which mounts are bind mounted. Additionally, the sandbox service runs mount directly, so there's no evidence of this particular type of bind mount in /etc/fstab either.
- Maura Dailey
On 08/21/2013 04:24 PM, Maura Dailey wrote:
Signed-off-by: Maura Dailey maura@eclipse.ncsc.mil
...mount_option_nodev_nonroot_local_partitions.xml | 28 ++++++++++--------- 1 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/RHEL6/input/checks/mount_option_nodev_nonroot_local_partitions.xml b/RHEL6/input/checks/mount_option_nodev_nonroot_local_partitions.xml index a5e6334..e0abd50 100644 --- a/RHEL6/input/checks/mount_option_nodev_nonroot_local_partitions.xml +++ b/RHEL6/input/checks/mount_option_nodev_nonroot_local_partitions.xml @@ -1,36 +1,38 @@
<def-group> - <definition class="compliance" id="mount_option_nodev_nonroot_local_partitions" version="1"> + <definition class="compliance" + id="mount_option_nodev_nonroot_local_partitions" version="1"> <metadata> <title>Add nodev Option to Non-Root Local Partitions</title> <affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected> - <description>The nodev mount option prevents files from being - interpreted as character or block devices. Legitimate character and block - devices should exist in the /dev directory on the root partition or - within chroot jails built for system services. All other locations should not - allow character and block devices.</description> + <description>The nodev mount option prevents files from being interpreted + as character or block devices. Legitimate character and block devices + should exist in the /dev directory on the root partition or within chroot + jails built for system services. All other locations should not allow + character and block devices.</description> + <reference source="MED" ref_id="20130821" ref_url="test_attestation" /> </metadata> <criteria> - <criterion comment="nodev on local filesystems" test_ref="test_nodev_nonroot_local_partitions" /> + <criterion comment="nodev on local filesystems" + test_ref="test_nodev_nonroot_local_partitions" negate="true" /> </criteria> </definition> - - <linux:partition_test check="all" check_existence="all_exist" id="test_nodev_nonroot_local_partitions" version="1" comment="nodev on local filesystems"> + <linux:partition_test check="all" check_existence="all_exist" + id="test_nodev_nonroot_local_partitions" version="1" + comment="nodev on local filesystems"> <linux:object object_ref="object_non_root_partitions" /> <linux:state state_ref="state_local_nodev" /> </linux:partition_test> - <linux:partition_object id="object_non_root_partitions" version="1"> <!-- look at all partitions except root --> <linux:mount_point operation="pattern match">^/\w.*$</linux:mount_point> <filter action="include">state_local_nodev</filter> </linux:partition_object> - <linux:partition_state id="state_local_nodev" version="1"> <!-- this check defines a local partition as one which has a device node in /dev --> <linux:device operation="pattern match">^/dev/.*$</linux:device> - <linux:mount_options datatype="string" entity_check="at least one" operation="equals">nodev</linux:mount_options> + <linux:mount_options datatype="string" entity_check="all" + operation="not equal">nodev</linux:mount_options> </linux:partition_state> - </def-group>
On 8/21/13 4:36 PM, Maura Dailey wrote:
One quick thing I forgot to add: this will give you false positives for bind mounted partitions, as I found out when I finally tracked a phantom non-existent /home partition (underneath an NFS mount in the same location) back to the sandbox service. /proc/mounts, which is where linux:partition_test apparently reads from, doesn't know or care which mounts are bind mounted. Additionally, the sandbox service runs mount directly, so there's no evidence of this particular type of bind mount in /etc/fstab either.
Definitely don't want deployments getting dinged about this, have to create a waiver, describe to their ISSO/ISSM, etc. Should the XCCDF be updated to reflect this known false positive?
On 08/21/2013 05:17 PM, Shawn Wells wrote:
On 8/21/13 4:36 PM, Maura Dailey wrote:
One quick thing I forgot to add: this will give you false positives for bind mounted partitions, as I found out when I finally tracked a phantom non-existent /home partition (underneath an NFS mount in the same location) back to the sandbox service. /proc/mounts, which is where linux:partition_test apparently reads from, doesn't know or care which mounts are bind mounted. Additionally, the sandbox service runs mount directly, so there's no evidence of this particular type of bind mount in /etc/fstab either.
Definitely don't want deployments getting dinged about this, have to create a waiver, describe to their ISSO/ISSM, etc. Should the XCCDF be updated to reflect this known false positive?
Unfortunately, the partition_test apparently reads directly from /proc/mounts, which doesn't list the bind option, so by itself, it's not equipped to solve this false positive. The only place the bind option will appear is in /etc/mtab or in /etc/fstab. In the case that had me stumped (the sandbox service runs the mount command at service start), nothing is going to be in /etc/fstab.
If we accept /etc/mtab as authoritative, I can rewrite the check using a textfilecontent54_test. There is a risk that an unmounted partition in /etc/fstab could escape detection, though. I haven't completely figured out how to solve that yet.
Either way, the existing check is busted, so it does have to be replaced.
- Maura Dailey
Do the thing that doesn't create false positives. Unmounted partitions are not a primary concern for this configuration. On the giant list of things to research (which never got done due to lack of resources) was how to control mount options for things dynamically mounted via gvfs/udev. This is where we should address the default mounting options for dynamic mounts. (Maybe worth investigating for RHEL 7).
Also, we should consider removing all description and title elements, and all id attributes, from the OVAL checks. Description and title could be programmatically added from the XCCDF, and the id from the filename. Not now, of course, but at some point.
Thanks again for the great work on this!
On Wed, Aug 21, 2013 at 5:52 PM, Maura Dailey maura@eclipse.ncsc.milwrote:
On 08/21/2013 05:17 PM, Shawn Wells wrote:
On 8/21/13 4:36 PM, Maura Dailey wrote:
One quick thing I forgot to add: this will give you false positives for bind mounted partitions, as I found out when I finally tracked a phantom non-existent /home partition (underneath an NFS mount in the same location) back to the sandbox service. /proc/mounts, which is where linux:partition_test apparently reads from, doesn't know or care which mounts are bind mounted. Additionally, the sandbox service runs mount directly, so there's no evidence of this particular type of bind mount in /etc/fstab either.
Definitely don't want deployments getting dinged about this, have to create a waiver, describe to their ISSO/ISSM, etc. Should the XCCDF be updated to reflect this known false positive?
Unfortunately, the partition_test apparently reads directly from /proc/mounts, which doesn't list the bind option, so by itself, it's not equipped to solve this false positive. The only place the bind option will appear is in /etc/mtab or in /etc/fstab. In the case that had me stumped (the sandbox service runs the mount command at service start), nothing is going to be in /etc/fstab.
If we accept /etc/mtab as authoritative, I can rewrite the check using a textfilecontent54_test. There is a risk that an unmounted partition in /etc/fstab could escape detection, though. I haven't completely figured out how to solve that yet.
Either way, the existing check is busted, so it does have to be replaced.
- Maura Dailey
______________________________**_________________ scap-security-guide mailing list scap-security-guide@lists.**fedorahosted.orgscap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.**org/mailman/listinfo/scap-**security-guidehttps://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On Wednesday, August 21, 2013 05:52:45 PM Maura Dailey wrote:
On 08/21/2013 05:17 PM, Shawn Wells wrote:
On 8/21/13 4:36 PM, Maura Dailey wrote:
One quick thing I forgot to add: this will give you false positives for bind mounted partitions, as I found out when I finally tracked a phantom non-existent /home partition (underneath an NFS mount in the same location) back to the sandbox service. /proc/mounts, which is where linux:partition_test apparently reads from, doesn't know or care which mounts are bind mounted. Additionally, the sandbox service runs mount directly, so there's no evidence of this particular type of bind mount in /etc/fstab either.
Definitely don't want deployments getting dinged about this, have to
create a waiver, describe to their ISSO/ISSM, etc. Should the XCCDF be updated to reflect this known false positive?
Unfortunately, the partition_test apparently reads directly from /proc/mounts, which doesn't list the bind option, so by itself, it's not equipped to solve this false positive.
Actually, the partition test is a fusion of data collected from /proc/mounts, getmntent_r(3), and statvfs of the filesystems. The proc call let's us know what to later to gather information. The getmntent_r call says it returns mount options and this is how its collected. If this is not getting the right options printed, then we need to know and make some fixes.
The only place the bind option will appear is in /etc/mtab or in /etc/fstab. In the case that had me stumped (the sandbox service runs the mount command at service start), nothing is going to be in /etc/fstab.
If we accept /etc/mtab as authoritative, I can rewrite the check using a textfilecontent54_test.
Being able to be used for this test is I think one of the main goals of the partition_test. (Mount options and disk space used I think was the main concerns.)
There is a risk that an unmounted partition in /etc/fstab could escape detection, though. I haven't completely figured out how to solve that yet.
Either way, the existing check is busted, so it does have to be replaced.
I might need to backtrack on this thread and see what's wrong. But partition_test should have all mount options.
-Steve
On 08/22/2013 02:44 PM, Steve Grubb wrote:
On Wednesday, August 21, 2013 05:52:45 PM Maura Dailey wrote:
On 08/21/2013 05:17 PM, Shawn Wells wrote:
On 8/21/13 4:36 PM, Maura Dailey wrote:
One quick thing I forgot to add: this will give you false positives for bind mounted partitions, as I found out when I finally tracked a phantom non-existent /home partition (underneath an NFS mount in the same location) back to the sandbox service. /proc/mounts, which is where linux:partition_test apparently reads from, doesn't know or care which mounts are bind mounted. Additionally, the sandbox service runs mount directly, so there's no evidence of this particular type of bind mount in /etc/fstab either.
Definitely don't want deployments getting dinged about this, have to
create a waiver, describe to their ISSO/ISSM, etc. Should the XCCDF be updated to reflect this known false positive?
Unfortunately, the partition_test apparently reads directly from /proc/mounts, which doesn't list the bind option, so by itself, it's not equipped to solve this false positive.
Actually, the partition test is a fusion of data collected from /proc/mounts, getmntent_r(3), and statvfs of the filesystems. The proc call let's us know what to later to gather information. The getmntent_r call says it returns mount options and this is how its collected. If this is not getting the right options printed, then we need to know and make some fixes.
The only place the bind option will appear is in /etc/mtab or in /etc/fstab. In the case that had me stumped (the sandbox service runs the mount command at service start), nothing is going to be in /etc/fstab.
If we accept /etc/mtab as authoritative, I can rewrite the check using a textfilecontent54_test.
Being able to be used for this test is I think one of the main goals of the partition_test. (Mount options and disk space used I think was the main concerns.)
There is a risk that an unmounted partition in /etc/fstab could escape detection, though. I haven't completely figured out how to solve that yet.
Either way, the existing check is busted, so it does have to be replaced.
I might need to backtrack on this thread and see what's wrong. But partition_test should have all mount options.
I tried the following unsuccessfully while troubleshooting how to detect a bind mount of /tmp on /var/tmp (another check):
First, I ran 'mount --bind /var/tmp /tmp
Then I tried this chunk of code in place of the mount_option_var_tmp_bind check: <linux:partition_test id ="test_mount_option_var_tmp_bind" version="1" comment="Detect bind mount" check="all"> <linux:object object_ref="object_mount_option_var_tmp_bind" /> </linux:partition_test>
<linux:partition_object id="object_mount_option_var_tmp_bind" version="1"> <linux:mount_point operation="pattern match">^.*$</linux:mount_point> </linux:partition_object>
I wasn't even trying to search for mount options yet, just get a complete list of all mounts. The resulting OVAL that testcheck.py generated did NOT show any bind mount options for any mount point detected. /var/tmp, which I was trying to detect, was an exact duplicate of /tmp's own mount section (and an exact duplicate out the output of /proc/mounts, which is where I developed my suspicions about the source of its data). I'm using oscap 0.9.3.
-Steve
On Thursday, August 22, 2013 03:09:33 PM Maura Dailey wrote:
I might need to backtrack on this thread and see what's wrong. But partition_test should have all mount options.
I tried the following unsuccessfully while troubleshooting how to detect a bind mount of /tmp on /var/tmp (another check):
First, I ran 'mount --bind /var/tmp /tmp
Then I tried this chunk of code in place of the mount_option_var_tmp_bind check: <linux:partition_test id ="test_mount_option_var_tmp_bind" version="1" comment="Detect bind mount" check="all"> <linux:object object_ref="object_mount_option_var_tmp_bind" /> </linux:partition_test>
<linux:partition_object id="object_mount_option_var_tmp_bind" version="1"> <linux:mount_point operation="pattern match">^.*$</linux:mount_point> </linux:partition_object>
I wasn't even trying to search for mount options yet, just get a complete list of all mounts. The resulting OVAL that testcheck.py generated did NOT show any bind mount options for any mount point detected. /var/tmp, which I was trying to detect, was an exact duplicate of /tmp's own mount section (and an exact duplicate out the output of /proc/mounts, which is where I developed my suspicions about the source of its data). I'm using oscap 0.9.3.
I wrote a test program to see what's happening. It would appear that the "bind" option is being dropped inside the kernel and its not reflected in /proc/mounts. However, the information is available in statvfs. So, if we need the bind flag, and I suspect we do, we can add it to the mount options returned by getmntent_r(3) in openscap's partition probe.
Do we need the bind mount flag?
-Steve
On Thursday, August 22, 2013 03:31:50 PM Steve Grubb wrote:
On Thursday, August 22, 2013 03:09:33 PM Maura Dailey wrote:
I might need to backtrack on this thread and see what's wrong. But partition_test should have all mount options.
I tried the following unsuccessfully while troubleshooting how to detect a bind mount of /tmp on /var/tmp (another check):
First, I ran 'mount --bind /var/tmp /tmp
Then I tried this chunk of code in place of the
mount_option_var_tmp_bind check: <linux:partition_test id ="test_mount_option_var_tmp_bind"
version="1" comment="Detect bind mount" check="all">
<linux:object object_ref="object_mount_option_var_tmp_bind" /></linux:partition_test>
<linux:partition_object id="object_mount_option_var_tmp_bind"
version="1">
<linux:mount_point operation="pattern match">^.*$</linux:mount_point></linux:partition_object>
I wasn't even trying to search for mount options yet, just get a complete list of all mounts. The resulting OVAL that testcheck.py generated did NOT show any bind mount options for any mount point detected. /var/tmp, which I was trying to detect, was an exact duplicate of /tmp's own mount section (and an exact duplicate out the output of /proc/mounts, which is where I developed my suspicions about the source of its data). I'm using oscap 0.9.3.
I wrote a test program to see what's happening. It would appear that the "bind" option is being dropped inside the kernel and its not reflected in /proc/mounts. However, the information is available in statvfs. So, if we need the bind flag, and I suspect we do, we can add it to the mount options returned by getmntent_r(3) in openscap's partition probe.
Do we need the bind mount flag?
In talking with Al Viro, he said that bind, move, and remount options are not displayed in /proc/mounts because its a "method" for creating the filesystem and not a "property" of the file system. The default method is "add". Of those, remount seems like something that is important for security assessment as well. It hides the real and permanent mount flags.
So, I think we can dig those out of the OS and append those to what we have in /proc/mounts. This would better reflect what is found by parsing /etc/fstab. But one things for sure, I don't think its specified where an OVAL probe looks to get the mount flags. So, there could be some variance in implementation. I'd probably need to give a hint on the OVAL devel list to make sure people know getmntent(3) is incomplete regarding mount methods.
-Steve
scap-security-guide@lists.fedorahosted.org
-
Jeffrey Blank -
Maura Dailey -
Shawn Wells -
Steve Grubb