[PATCH] exclude /sys from search in world_writeable_files
sgrubb at redhat.com
Thu May 22 15:11:59 UTC 2014
On Thu, 22 May 2014 08:16:24 -0400
"Paul Tittle (Contractor)" <ptittle at cmf.nrl.navy.mil> wrote:
> Thanks for the ack, Jan. Pushed.
> There is at least one more check that has the same issue of searching
> /proc and /sys. I'm not sure I should submit patches for those other
> checks because there's discussion on the openscap list about how to
> more precisely define what a 'local' filesystem is.
> This will probably lead to a philosophical discussion about whether
> or not we should define /proc and /sys as local filesystems.
They are local file systems. Remote file systems are things that are
shared or sharable with other systems. For example, you do not want
to descend into /home if the users are supplied by nscd and have nfs
automounting setup. You'll create a mount storm. I raised this topic on
the OVAL devel mail list to clarify it and to also discuss recursion.
When descending filesystems, you should not follow symlinks -
especially in /proc. (/proc is a special file system with ownership and
permissions enforced internally, so no external scan will be
meaningful because there is no corrective action possible.) I also do
not recommend scanning /dev because sometimes watchdog timers live over
there and accessing them sets off an eventual system reset.
> If we declare them as not local, then there's no way to search them
> with a recurse_file_system="local" behavior. Not the worst problem to
> have, as you would just define another file_object just for special
> filesystems if your check really had to look in /proc and /sys. But
> if we define them as not local, that sounds strange because they are,
> of course, local filesystems.
There was an issue raised last fall on the RHEL5 USGCB content around
this and it was addressed. The RHEL6 content shold be updated to follow
the same fix that RHEL5 got.
> It seems like OVAL should have other recurse_file_system values, such
> as 'normal' and 'special'. 'normal' could mean a filesystem that
> represents regular data on a disk somewhere, and 'special' could
> be /proc, /sys, and other filesystems that are useful abstractions
> but otherwise aren't backed by storage.
In a lot of cases searching them is meaningless. What I think needs
work is setting clear expectations around the symlink + recursion
options. I want to believe MITRE agreed and had a tracker for it.
More information about the scap-security-guide