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