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.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
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide