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