That would remove the issues of catching things in /proc, which is probably where there is
the most 'churn' in terms of 'files' appearing and disappearing rapidly.
There would still be the occasional case where a file exists when 'find' scans a
directory for files but doesn't exists by the time 'find' loops throught
entries to actually look at it. I haven't look back historically to see when the
'-ignore_readdir_race' flag appeared, so I haven't a clue how often such a
race condition occurs.
-Rob
________________________________
From: scap-security-guide-bounces(a)lists.fedorahosted.org
[scap-security-guide-bounces(a)lists.fedorahosted.org] on behalf of Shawn Wells
[shawn(a)redhat.com]
Sent: Monday, July 22, 2013 9:27 PM
To: scap-security-guide(a)lists.fedorahosted.org
Subject: Re: Suggestion on the 'Ensure All Files Are Owned...' items
On 7/19/13 1:52 PM, Andrew Gilmore wrote:
I agree, I see false positives on my systems where the only output
from a manual 'sudo find / -type f -perm o+w' is errors on /proc
directories.
Andrew
On Thu, Jul 18, 2013 at 11:11 AM, Robert Sanders
<rsanders@trustedcs.com><mailto:rsanders@trustedcs.com> wrote:
I was wondering why the tests for 'Ensure all Files Are Owned by
a User' and
'Ensure all Files are Owned by a Group' kept on failing. Drilling down it
looks like the underlying find command being used is along the lines of :
find PARTITION -xdev -nouser -print
When I run this command manually I've had complaints that find can't read
files in /proc. Looking at the man page suggests this can be avoided by
adding the '-ignore_readdir_race' option before the -xdev option.
This change may need to be added for both SSG items 2.2.3.e and 2.2.3.f
-Rob
Hmm. The OVAL spec is here (search for " == FileBehaviors =="):
http://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation...
And our OVAL:
<unix:file_object comment="all local files"
id="obj_20022" version="1">
<unix:behaviors recurse="symlinks and directories"
recurse_file_system="local" />
<unix:path>/</unix:path>
<unix:filename operation="pattern match">.*</unix:filename>
</unix:file_object>
According to the spec, it should be possible to use
recurse_file_system="defined", and use the unix:filename to create a regex that
excludes /proc
Maura seems to have the best regex skills.... ;)