[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

Maura Dailey maura at eclipse.ncsc.mil
Thu Aug 22 19:09:33 UTC 2013


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




More information about the scap-security-guide mailing list