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(a)eclipse.ncsc.mil>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. 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.org<scap-security-guide(a)lists.fedorahosted.org>
https://lists.fedorahosted.**org/mailman/listinfo/scap-**security-guide&l...