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
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 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
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
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 Sandersrsanders@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/li...
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.... ;)
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@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Shawn Wells [shawn@redhat.com] Sent: Monday, July 22, 2013 9:27 PM To: scap-security-guide@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.commailto: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/li...
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.... ;)
If we're talking about the same checks, file_permissions_unowned and file_permissions_ungroupowned, I'd like to point out that the checks as written are seriously broken. Both only look for files, not directories, and according to the comments, both claim to look for the setuid bit, but are actually just checking to see if the owner or group is root or not (user and group id 0).
Does anyone actually have a way to "unown" or "ungroup own" a file for testing purposes? I'd like to see if the uid shows up as 0 or as xsi:nil.
- Maura Dailey
On 07/23/2013 08:59 AM, Robert Sanders wrote:
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@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Shawn Wells [shawn@redhat.com] *Sent:* Monday, July 22, 2013 9:27 PM *To:* scap-security-guide@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 Sandersrsanders@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/li...
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.... ;)
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Hmm, these tests should be simply a permutation of find / -type f -nouser or -nogroup.
It appeared to me that the standard WAS specifying only files, and not directories.
If you want to be sure you're not scanning network shares, I suppose some iteration through local partitions, either as returned by mount(1) or some other magic would be necessary, but the find command is generally the same. I like the -ignore_readdir_race fix, too.
Andrew
On Tue, Jul 23, 2013 at 11:23 AM, Gary Gapinski gapinski@nasa.gov wrote:
On 07/23/2013 01:17 PM, Maura Dailey wrote:
Does anyone actually have a way to "unown" or "ungroup own" a file for testing purposes? I'd like to see if the uid shows up as 0 or as xsi:nil.
chown <pick some unused uid> file chgrp <pick some unused gid> file
Regards,
Gary
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 07/23/2013 01:23 PM, Gary Gapinski wrote:
On 07/23/2013 01:17 PM, Maura Dailey wrote:
Does anyone actually have a way to "unown" or "ungroup own" a file for testing purposes? I'd like to see if the uid shows up as 0 or as xsi:nil.
chown <pick some unused uid> file chgrp <pick some unused gid> file
Huh, didn't realize that was all we were testing for. That makes it way harder to test in OVAL, obviously, since the normal file test will happily report whatever value it finds without checking if it's assigned to a user or group.
Regards,
Gary
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On Tuesday, July 23, 2013 02:04:48 PM Maura Dailey wrote:
On 07/23/2013 01:23 PM, Gary Gapinski wrote:
On 07/23/2013 01:17 PM, Maura Dailey wrote:
Does anyone actually have a way to "unown" or "ungroup own" a file for testing purposes? I'd like to see if the uid shows up as 0 or as xsi:nil.
chown <pick some unused uid> file chgrp <pick some unused gid> file
Huh, didn't realize that was all we were testing for. That makes it way harder to test in OVAL, obviously, since the normal file test will happily report whatever value it finds without checking if it's assigned to a user or group.
This test is correctly working in RHEL5 USGCB. There is a variable with local user ID's:
<ind-def:textfilecontent54_object id="oval:gov.nist.usgcb.rhel:obj:200501" version="1"> ind-def:filepath/etc/passwd</ind-def:filepath> <ind-def:pattern operation="pattern match">^[^:]+:[^:]+:([\d]+):[\d]+:[^:]*:[^:]+:[^:]*$</ind-def:pattern> <ind-def:instance operation="greater than or equal" datatype="int">1</ind-def:instance> </ind-def:textfilecontent54_object>
And this is used in another test: <unix-def:file_state id="oval:gov.nist.usgcb.rhel:ste:20050" version="1" comment="Files with a valid user id assigned"> <unix-def:user_id datatype="int" var_check="at least one" var_ref="oval:gov.nist.usgcb.rhel:var:200501"/> </unix-def:file_state>
which checks the results of recursing the local file system:
<unix-def:file_object id="oval:gov.nist.usgcb.rhel:obj:20050" version="1" comment="all local files without a valid user assigned"> <unix-def:behaviors recurse="directories" recurse_direction="down" recurse_file_system="local"/> unix-def:path/</unix-def:path> <unix-def:filename operation="pattern match">.*</unix-def:filename> <filter>oval:gov.nist.usgcb.rhel:ste:20050</filter> </unix-def:file_object>
This was working in the past.
-Steve
That's about where I was going with it just now, actually (although I was unsuccessfully trying something more complicated with the password_test and password_object OVAL pieces), but do we have to solve network user ids as well? Or do you think it is sufficient in this check to just check local accounts?
- Maura Dailey
On 07/23/2013 02:19 PM, Steve Grubb wrote:
On Tuesday, July 23, 2013 02:04:48 PM Maura Dailey wrote:
On 07/23/2013 01:23 PM, Gary Gapinski wrote:
On 07/23/2013 01:17 PM, Maura Dailey wrote:
Does anyone actually have a way to "unown" or "ungroup own" a file for testing purposes? I'd like to see if the uid shows up as 0 or as xsi:nil.
chown <pick some unused uid> file chgrp <pick some unused gid> file
Huh, didn't realize that was all we were testing for. That makes it way harder to test in OVAL, obviously, since the normal file test will happily report whatever value it finds without checking if it's assigned to a user or group.
This test is correctly working in RHEL5 USGCB. There is a variable with local user ID's:
<ind-def:textfilecontent54_object id="oval:gov.nist.usgcb.rhel:obj:200501" version="1"> <ind-def:filepath>/etc/passwd</ind-def:filepath> <ind-def:pattern operation="pattern match">^[^:]+:[^:]+:([\d]+):[\d]+:[^:]*:[^:]+:[^:]*$</ind-def:pattern> <ind-def:instance operation="greater than or equal" datatype="int">1</ind-def:instance> </ind-def:textfilecontent54_object>
And this is used in another test: <unix-def:file_state id="oval:gov.nist.usgcb.rhel:ste:20050" version="1" comment="Files with a valid user id assigned"> <unix-def:user_id datatype="int" var_check="at least one" var_ref="oval:gov.nist.usgcb.rhel:var:200501"/> </unix-def:file_state>
which checks the results of recursing the local file system:
<unix-def:file_object id="oval:gov.nist.usgcb.rhel:obj:20050" version="1" comment="all local files without a valid user assigned"> <unix-def:behaviors recurse="directories" recurse_direction="down" recurse_file_system="local"/> <unix-def:path>/</unix-def:path> <unix-def:filename operation="pattern match">.*</unix-def:filename> <filter>oval:gov.nist.usgcb.rhel:ste:20050</filter> </unix-def:file_object>
This was working in the past.
-Steve
On Tuesday, July 23, 2013 02:24:22 PM Maura Dailey wrote:
That's about where I was going with it just now, actually (although I was unsuccessfully trying something more complicated with the password_test and password_object OVAL pieces), but do we have to solve network user ids as well? Or do you think it is sufficient in this check to just check local accounts?
I don't think this benchmark addressed network based user accounts. I'm not even sure there is proper support in OVAL for that. If it did, it would require a specific pam setup, or NIS+, or sssd. Because of the variations in how to do it, I don't think there is a clear cut best way to do it. So, I'd only concentrate on local users and leave network users out for now.
-Steve
On 07/23/2013 02:49 PM, Steve Grubb wrote:
I don't think this benchmark addressed network based user accounts. I'm not even sure there is proper support in OVAL for that. If it did, it would require a specific pam setup, or NIS+, or sssd. Because of the variations in how to do it, I don't think there is a clear cut best way to do it. So, I'd only concentrate on local users and leave network users out for now.
Would (not) systems which extend the authentication domain with network based accounts show false positives on such tests based solely on uids and gids from /etc/passwd and /etc/group?
On Tuesday, July 23, 2013 03:10:09 PM Gary Gapinski wrote:
On 07/23/2013 02:49 PM, Steve Grubb wrote:
I don't think this benchmark addressed network based user accounts. I'm not even sure there is proper support in OVAL for that. If it did, it would require a specific pam setup, or NIS+, or sssd. Because of the variations in how to do it, I don't think there is a clear cut best way to do it. So, I'd only concentrate on local users and leave network users out for now.
Would (not) systems which extend the authentication domain with network based accounts show false positives on such tests based solely on uids and gids from /etc/passwd and /etc/group?
Probably. But the places that you might run into this is limited, /var/spool, /var/mail, /home, /tmp. But looking at the guide, 2.4.1.2, its clearly talking about /etc/passwd and groups. And nowhere else do I see guidance on how to configure remote authentication. Like I said, I don't know if OVAL can even support remote user lookup given 3 or 4 ways to do it.
I'd also be curious if the find command gets it right.
-Steve
Just an aside, I did some poking around, and it is possible to eliminate directories from the search. I looked at the USGCB stuffs and here's what I put together for file_permissions_unowned.xml in OVAL to eliminate /proc. I can do the same for the group id version. To add more exclusions, add an '|' after proc, and type in another directory path. It doesn't seem to care if you escape the forward slashes, but I left that in just in case the behavior changes later.
If anyone does figure out how to query PAM or nslcd/nscd for network user ids, I think you can add it as an extra filter option to the file_permissions_unowned_object.
Please note, I have not gotten a single failure with this check against /proc. I get thousands of failures on my workstation, since I have large git repositories checked out to directories owned by my network account on the root hard drive.
|<def-group>|| || <definition class="compliance" id="file_permissions_unowned" version="1">|| || <metadata>|| || <title>Find files unowned by a user</title>|| || <affected family="unix">|| || <platform>Red Hat Enterprise Linux 6</platform>|| || </affected>|| || <description>All files should be owned by a user</description>|| || </metadata>|| || <criteria>|| || <criterion comment="Check all files and make sure they are owned by a user" test_ref="file_permissions_unowned_test" />|| || </criteria>|| || </definition>|| || || <unix:file_state id="file_permissions_unowned_userid_list_match" version="1">|| || <unix:user_id var_check="at least one" var_ref="file_permissions_unowned_userid_list" datatype="int" />|| || </unix:file_state>|| || || <local_variable id="file_permissions_unowned_userid_list" comment="List of valid user ids" datatype="int" version="1">|| || <object_component item_field="subexpression" object_ref="file_permissions_unowned_userid_list_object" />|| || </local_variable>|| || || <ind:textfilecontent54_object id="file_permissions_unowned_userid_list_object" version="1">|| ||ind:filepath/etc/passwd</ind:filepath>|| || <ind:pattern operation="pattern match">^[^:]+:[^:]+:([\d]+):[\d]+:[^:]*:[^:]+:[^:]*$</ind:pattern>|| || <ind:instance operation="greater than or equal" datatype="int">1</ind:instance>|| || </ind:textfilecontent54_object>|| || || <unix:file_object comment="all local files" id="file_permissions_unowned_object" version="1">|| || <unix:behaviors recurse="symlinks and directories" recurse_direction="down" recurse_file_system="local" />|| || <unix:filepath operation="pattern match">^(?!/proc)/</unix:filepath>|| || <filter action="exclude">file_permissions_unowned_userid_list_match</filter>|| || </unix:file_object>|| || || <unix:file_test check="all" check_existence="none_exist" comment="Check user ids on all files on the system" id="file_permissions_unowned_test" version="1">|| || <unix:object object_ref="file_permissions_unowned_object" />|| || </unix:file_test>|| ||</def-group>|
- Maura Dailey
I, along with Robert, assumed that the test was using some sort of find(1) invocation. It appears not to be, although this OVAL is pretty opaque to me.
When I see the current check failing against my system, I then run a find command, and the only output is complaints about /proc entries. I then assumed that this output was why the check was failing.
I can confirm that this check does fail against my system, or at least that testcheck returns false. The results file points at /.autofsck and /.readahead_collect, which doesn't make sense at all.
This is one of the more frustrating false positives that I have.
Andrew
On Tue, Jul 23, 2013 at 1:47 PM, Maura Dailey maura@eclipse.ncsc.milwrote:
Just an aside, I did some poking around, and it is possible to eliminate directories from the search. I looked at the USGCB stuffs and here's what I put together for file_permissions_unowned.xml in OVAL to eliminate /proc. I can do the same for the group id version. To add more exclusions, add an '|' after proc, and type in another directory path. It doesn't seem to care if you escape the forward slashes, but I left that in just in case the behavior changes later.
If anyone does figure out how to query PAM or nslcd/nscd for network user ids, I think you can add it as an extra filter option to the file_permissions_unowned_object.
Please note, I have not gotten a single failure with this check against /proc. I get thousands of failures on my workstation, since I have large git repositories checked out to directories owned by my network account on the root hard drive.
<def-group> <definition class="compliance" id="file_permissions_unowned" version="1"> <metadata> <title>Find files unowned by a user</title> <affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected> <description>All files should be owned by a user</description> </metadata> <criteria> <criterion comment="Check all files and make sure they are owned by a user" test_ref="file_permissions_unowned_test" /> </criteria> </definition>
<unix:file_state id="file_permissions_unowned_userid_list_match" version="1"> <unix:user_id var_check="at least one" var_ref="file_permissions_unowned_userid_list" datatype="int" /> </unix:file_state>
<local_variable id="file_permissions_unowned_userid_list" comment="List of valid user ids" datatype="int" version="1"> <object_component item_field="subexpression" object_ref="file_permissions_unowned_userid_list_object" />
</local_variable>
<ind:textfilecontent54_object id="file_permissions_unowned_userid_list_object" version="1"> ind:filepath/etc/passwd</ind:filepath> <ind:pattern operation="pattern match">^[^:]+:[^:]+:([\d]+):[\d]+:[^:]*:[^:]+:[^:]*$</ind:pattern> <ind:instance operation="greater than or equal" datatype="int">1</ind:instance> </ind:textfilecontent54_object>
<unix:file_object comment="all local files" id="file_permissions_unowned_object" version="1"> <unix:behaviors recurse="symlinks and directories" recurse_direction="down" recurse_file_system="local" /> <unix:filepath operation="pattern match">^(?!/proc)/</unix:filepath> <filter action="exclude">file_permissions_unowned_userid_list_match</filter> </unix:file_object>
<unix:file_test check="all" check_existence="none_exist" comment="Check user ids on all files on the system" id="file_permissions_unowned_test" version="1"> <unix:object object_ref="file_permissions_unowned_object" /> </unix:file_test>
</def-group>
- Maura Dailey
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
I was absolutely doing the 'find' check to see why this item failed, as that was the guidance I saw listed in the <check-content> tags for both the no_files_unowned_by_user and no_files_unowned_by_group Rules , which I assumed (perhaps naively) was actually being done. I started triaging this because the scans run by oscap with the SSG content were indicating a problem, but Security Blanket (which isn't using find) were saying all was well. Started digging around to find out why.
-Rob
________________________________ From: scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Andrew Gilmore [agilmore2@gmail.com] Sent: Tuesday, July 23, 2013 4:31 PM To: scap-security-guide@lists.fedorahosted.org Subject: Re: Suggestion on the 'Ensure All Files Are Owned...' items
I, along with Robert, assumed that the test was using some sort of find(1) invocation. It appears not to be, although this OVAL is pretty opaque to me.
When I see the current check failing against my system, I then run a find command, and the only output is complaints about /proc entries. I then assumed that this output was why the check was failing.
I can confirm that this check does fail against my system, or at least that testcheck returns false. The results file points at /.autofsck and /.readahead_collect, which doesn't make sense at all.
This is one of the more frustrating false positives that I have.
Andrew
On Tue, Jul 23, 2013 at 1:47 PM, Maura Dailey <maura@eclipse.ncsc.milmailto:maura@eclipse.ncsc.mil> wrote: Just an aside, I did some poking around, and it is possible to eliminate directories from the search. I looked at the USGCB stuffs and here's what I put together for file_permissions_unowned.xml in OVAL to eliminate /proc. I can do the same for the group id version. To add more exclusions, add an '|' after proc, and type in another directory path. It doesn't seem to care if you escape the forward slashes, but I left that in just in case the behavior changes later.
If anyone does figure out how to query PAM or nslcd/nscd for network user ids, I think you can add it as an extra filter option to the file_permissions_unowned_object.
Please note, I have not gotten a single failure with this check against /proc. I get thousands of failures on my workstation, since I have large git repositories checked out to directories owned by my network account on the root hard drive.
<def-group> <definition class="compliance" id="file_permissions_unowned" version="1"> <metadata> <title>Find files unowned by a user</title> <affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected> <description>All files should be owned by a user</description> </metadata> <criteria> <criterion comment="Check all files and make sure they are owned by a user" test_ref="file_permissions_unowned_test" /> </criteria> </definition>
<unix:file_state id="file_permissions_unowned_userid_list_match" version="1"> <unix:user_id var_check="at least one" var_ref="file_permissions_unowned_userid_list" datatype="int" /> </unix:file_state>
<local_variable id="file_permissions_unowned_userid_list" comment="List of valid user ids" datatype="int" version="1"> <object_component item_field="subexpression" object_ref="file_permissions_unowned_userid_list_object" /> </local_variable>
<ind:textfilecontent54_object id="file_permissions_unowned_userid_list_object" version="1"> ind:filepath/etc/passwd</ind:filepath> <ind:pattern operation="pattern match">^[^:]+:[^:]+:([\d]+):[\d]+:[^:]*:[^:]+:[^:]*$</ind:pattern> <ind:instance operation="greater than or equal" datatype="int">1</ind:instance> </ind:textfilecontent54_object>
<unix:file_object comment="all local files" id="file_permissions_unowned_object" version="1"> <unix:behaviors recurse="symlinks and directories" recurse_direction="down" recurse_file_system="local" /> <unix:filepath operation="pattern match">^(?!/proc)/</unix:filepath> <filter action="exclude">file_permissions_unowned_userid_list_match</filter> </unix:file_object>
<unix:file_test check="all" check_existence="none_exist" comment="Check user ids on all files on the system" id="file_permissions_unowned_test" version="1"> <unix:object object_ref="file_permissions_unowned_object" /> </unix:file_test> </def-group>
- Maura Dailey
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
The current check that's checked into git is broken. The permissions_ungroupowned.xml check is searching the local file system for things with group_id set to 0 and negating the result of the check. That's all it's doing. The permissions_unowned.xml check was doing the same thing, but with user_ids set to 0. I feel like it was guaranteed to fail.
On 07/23/2013 04:31 PM, Andrew Gilmore wrote:
I, along with Robert, assumed that the test was using some sort of find(1) invocation. It appears not to be, although this OVAL is pretty opaque to me.
When I see the current check failing against my system, I then run a find command, and the only output is complaints about /proc entries. I then assumed that this output was why the check was failing.
I can confirm that this check does fail against my system, or at least that testcheck returns false. The results file points at /.autofsck and /.readahead_collect, which doesn't make sense at all.
This is one of the more frustrating false positives that I have.
Andrew
On Tue, Jul 23, 2013 at 1:47 PM, Maura Dailey <maura@eclipse.ncsc.mil mailto:maura@eclipse.ncsc.mil> wrote:
Just an aside, I did some poking around, and it is possible to eliminate directories from the search. I looked at the USGCB stuffs and here's what I put together for file_permissions_unowned.xml in OVAL to eliminate /proc. I can do the same for the group id version. To add more exclusions, add an '|' after proc, and type in another directory path. It doesn't seem to care if you escape the forward slashes, but I left that in just in case the behavior changes later. If anyone does figure out how to query PAM or nslcd/nscd for network user ids, I think you can add it as an extra filter option to the file_permissions_unowned_object. Please note, I have not gotten a single failure with this check against /proc. I get thousands of failures on my workstation, since I have large git repositories checked out to directories owned by my network account on the root hard drive. |<def-group>|| || <definition class="compliance" id="file_permissions_unowned" version="1">|| || <metadata>|| || <title>Find files unowned by a user</title>|| || <affected family="unix">|| || <platform>Red Hat Enterprise Linux 6</platform>|| || </affected>|| || <description>All files should be owned by a user</description>|| || </metadata>|| || <criteria>|| || <criterion comment="Check all files and make sure they are owned by a user" test_ref="file_permissions_unowned_test" />|| || </criteria>|| || </definition>|| || || <unix:file_state id="file_permissions_unowned_userid_list_match" version="1">|| || <unix:user_id var_check="at least one" var_ref="file_permissions_unowned_userid_list" datatype="int" />|| || </unix:file_state>|| || || <local_variable id="file_permissions_unowned_userid_list" comment="List of valid user ids" datatype="int" version="1">|| || <object_component item_field="subexpression" object_ref="file_permissions_unowned_userid_list_object" />|| || </local_variable>|| || || <ind:textfilecontent54_object id="file_permissions_unowned_userid_list_object" version="1">|| ||<ind:filepath>/etc/passwd</ind:filepath>|| || <ind:pattern operation="pattern match">^[^:]+:[^:]+:([\d]+):[\d]+:[^:]*:[^:]+:[^:]*$</ind:pattern>|| || <ind:instance operation="greater than or equal" datatype="int">1</ind:instance>|| || </ind:textfilecontent54_object>|| || || <unix:file_object comment="all local files" id="file_permissions_unowned_object" version="1">|| || <unix:behaviors recurse="symlinks and directories" recurse_direction="down" recurse_file_system="local" />|| || <unix:filepath operation="pattern match">^(?!\/proc)/</unix:filepath>|| || <filter action="exclude">file_permissions_unowned_userid_list_match</filter>|| || </unix:file_object>|| || || <unix:file_test check="all" check_existence="none_exist" comment="Check user ids on all files on the system" id="file_permissions_unowned_test" version="1">|| || <unix:object object_ref="file_permissions_unowned_object" />|| || </unix:file_test>|| ||</def-group>| - Maura Dailey _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Just to add on to what I said, I'm positive the current checks weren't actually doing recursion at all. You can tell by how quickly they return. In which case, yes, the results "make sense," because it successfully finds the only files in / that belong to root, negates the result, and prints false.
- Maura Dailey
On 07/23/2013 05:12 PM, Maura Dailey wrote:
The current check that's checked into git is broken. The permissions_ungroupowned.xml check is searching the local file system for things with group_id set to 0 and negating the result of the check. That's all it's doing. The permissions_unowned.xml check was doing the same thing, but with user_ids set to 0. I feel like it was guaranteed to fail.
On 07/23/2013 04:31 PM, Andrew Gilmore wrote:
I, along with Robert, assumed that the test was using some sort of find(1) invocation. It appears not to be, although this OVAL is pretty opaque to me.
When I see the current check failing against my system, I then run a find command, and the only output is complaints about /proc entries. I then assumed that this output was why the check was failing.
I can confirm that this check does fail against my system, or at least that testcheck returns false. The results file points at /.autofsck and /.readahead_collect, which doesn't make sense at all.
This is one of the more frustrating false positives that I have.
Andrew
On Tue, Jul 23, 2013 at 1:47 PM, Maura Dailey <maura@eclipse.ncsc.mil mailto:maura@eclipse.ncsc.mil> wrote:
Just an aside, I did some poking around, and it is possible to eliminate directories from the search. I looked at the USGCB stuffs and here's what I put together for file_permissions_unowned.xml in OVAL to eliminate /proc. I can do the same for the group id version. To add more exclusions, add an '|' after proc, and type in another directory path. It doesn't seem to care if you escape the forward slashes, but I left that in just in case the behavior changes later. If anyone does figure out how to query PAM or nslcd/nscd for network user ids, I think you can add it as an extra filter option to the file_permissions_unowned_object. Please note, I have not gotten a single failure with this check against /proc. I get thousands of failures on my workstation, since I have large git repositories checked out to directories owned by my network account on the root hard drive. |<def-group>|| || <definition class="compliance" id="file_permissions_unowned" version="1">|| || <metadata>|| || <title>Find files unowned by a user</title>|| || <affected family="unix">|| || <platform>Red Hat Enterprise Linux 6</platform>|| || </affected>|| || <description>All files should be owned by a user</description>|| || </metadata>|| || <criteria>|| || <criterion comment="Check all files and make sure they are owned by a user" test_ref="file_permissions_unowned_test" />|| || </criteria>|| || </definition>|| || || <unix:file_state id="file_permissions_unowned_userid_list_match" version="1">|| || <unix:user_id var_check="at least one" var_ref="file_permissions_unowned_userid_list" datatype="int" />|| || </unix:file_state>|| || || <local_variable id="file_permissions_unowned_userid_list" comment="List of valid user ids" datatype="int" version="1">|| || <object_component item_field="subexpression" object_ref="file_permissions_unowned_userid_list_object" />|| || </local_variable>|| || || <ind:textfilecontent54_object id="file_permissions_unowned_userid_list_object" version="1">|| ||<ind:filepath>/etc/passwd</ind:filepath>|| || <ind:pattern operation="pattern match">^[^:]+:[^:]+:([\d]+):[\d]+:[^:]*:[^:]+:[^:]*$</ind:pattern>|| || <ind:instance operation="greater than or equal" datatype="int">1</ind:instance>|| || </ind:textfilecontent54_object>|| || || <unix:file_object comment="all local files" id="file_permissions_unowned_object" version="1">|| || <unix:behaviors recurse="symlinks and directories" recurse_direction="down" recurse_file_system="local" />|| || <unix:filepath operation="pattern match">^(?!\/proc)/</unix:filepath>|| || <filter action="exclude">file_permissions_unowned_userid_list_match</filter>|| || </unix:file_object>|| || || <unix:file_test check="all" check_existence="none_exist" comment="Check user ids on all files on the system" id="file_permissions_unowned_test" version="1">|| || <unix:object object_ref="file_permissions_unowned_object" />|| || </unix:file_test>|| ||</def-group>| - Maura Dailey _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Hi,
I've browsed through the thread and have several remarks.
- the tree under /sys causes the same problems a /proc and should be filtered out
- OpenSCAP should already consider these as not "local" which mitigates this problem a bit, but that doesn't help much from SSG's POV
- in the example below, the 'behaviors' element is redundant, as the specs [1] put it:
the 'max_depth' and 'recurse_direction' attributes of the 'behaviors' element do not apply to the 'filepath' element, only to the 'path' and 'filename' elements.
On 07/23/2013 09:47 PM, Maura Dailey wrote:
I looked at the USGCB stuffs and here's what I put together for file_permissions_unowned.xml in OVAL to eliminate /proc.
<unix:file_object comment="all local files" id="file_permissions_unowned_object" version="1"> <unix:behaviors recurse="symlinks and directories" recurse_direction="down" recurse_file_system="local" /> <unix:filepath operation="pattern match">^(?!/proc)/</unix:filepath>
You don't want to do this ^^^. This tries to match a regexp to every file on the system. You should rather use something along the lines of:
<unix:behaviors recurse="symlinks and directories" recurse_direction="down" recurse_file_system="local" max_depth="-1"/> <unix:path operation="pattern match">^/(?!proc/)[^/]*/$</unix:path> <unix:filename operation="pattern match">^.*$</unix:filename>
The regex in 'path' just matches a top-level directory and the recursion follows from each of them, which should be faster.
[1] http://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/un...
Tomas
On 07/25/2013 12:31 PM, Tomas Heinrich wrote:
Hi,
I've browsed through the thread and have several remarks.
- the tree under /sys causes the same problems a /proc and should be
filtered out
- OpenSCAP should already consider these as not "local" which
mitigates this problem a bit, but that doesn't help much from SSG's POV
- in the example below, the 'behaviors' element is redundant, as the
specs [1] put it:
the 'max_depth' and 'recurse_direction' attributes of the 'behaviors' element do not apply to the 'filepath' element, only to the 'path' and 'filename' elements.
On 07/23/2013 09:47 PM, Maura Dailey wrote:
I looked at the USGCB stuffs and here's what I put together for file_permissions_unowned.xml in OVAL to eliminate /proc.
<unix:file_object comment="all local files" id="file_permissions_unowned_object" version="1"> <unix:behaviors recurse="symlinks and directories" recurse_direction="down" recurse_file_system="local" /> <unix:filepath operation="pattern match">^(?!/proc)/</unix:filepath>
You don't want to do this ^^^. This tries to match a regexp to every file on the system. You should rather use something along the lines of:
<unix:behaviors recurse="symlinks and directories" recurse_direction="down" recurse_file_system="local" max_depth="-1"/> <unix:path operation="pattern match">^/(?!proc/)[^/]*/$</unix:path> <unix:filename operation="pattern match">^.*$</unix:filename>
The regex in 'path' just matches a top-level directory and the recursion follows from each of them, which should be faster.
[1] http://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/un...
Thanks for the correction. I don't have a good intuitive grasp on OVAL's regex support yet. I switched to filepath because I was fighting with path and filename unsuccessfully.
Tomas
- Maura Dailey
First, I'd like to point out that my /proc and /sys is never searched. Or /tmp. All three are separate partitions on my system, but I'm not sure if that's related.
I've tested your suggested change with some success, but not great success. The first problem is that unix:path will never return a result that ends in a /.
So far: <unix:file_object comment="all local files" id="object_file_permissions_unowned" version="1"> <unix:behaviors recurse="symlinks and directories" recurse_direction="down" recurse_file_system="local" max_depth="-1" /> <unix:path operation="pattern match">^/(?!proc|sys)[^/]*$</unix:path> <unix:filename operation="pattern match">^.*$</unix:filename> <filter action="exclude">file_permissions_unowned_userid_list_match</filter> </unix:file_object>
Results in: Nothing with /proc or /sys is returned, but the test file file /meh isn't returned either.
My regex is pretty rudimentary. If you have an idea for a change that will match /meh, let me know. I have to substitute different directory names for proc and sys to ensure it's working correctly, since, as I said above, I never get results for /proc and /sys.
(My single line unix:filepath will let me exclude directories, while still returning the file /meh. This makes my inability to get it to work in two lines frustrating.)
- Maura Dailey
On 07/25/2013 12:31 PM, Tomas Heinrich wrote:
Hi,
I've browsed through the thread and have several remarks.
- the tree under /sys causes the same problems a /proc and should be
filtered out
- OpenSCAP should already consider these as not "local" which
mitigates this problem a bit, but that doesn't help much from SSG's POV
- in the example below, the 'behaviors' element is redundant, as the
specs [1] put it:
the 'max_depth' and 'recurse_direction' attributes of the 'behaviors' element do not apply to the 'filepath' element, only to the 'path' and 'filename' elements.
On 07/23/2013 09:47 PM, Maura Dailey wrote:
I looked at the USGCB stuffs and here's what I put together for file_permissions_unowned.xml in OVAL to eliminate /proc.
<unix:file_object comment="all local files" id="file_permissions_unowned_object" version="1"> <unix:behaviors recurse="symlinks and directories" recurse_direction="down" recurse_file_system="local" /> <unix:filepath operation="pattern match">^(?!/proc)/</unix:filepath>
You don't want to do this ^^^. This tries to match a regexp to every file on the system. You should rather use something along the lines of:
<unix:behaviors recurse="symlinks and directories" recurse_direction="down" recurse_file_system="local" max_depth="-1"/> <unix:path operation="pattern match">^/(?!proc/)[^/]*/$</unix:path> <unix:filename operation="pattern match">^.*$</unix:filename>
The regex in 'path' just matches a top-level directory and the recursion follows from each of them, which should be faster.
[1] http://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/un...
Tomas
On Tuesday, July 23, 2013 03:30:45 PM Steve Grubb wrote:
I'd also be curious if the find command gets it right.
setpwent (); while ((pw = getpwent ()) != NULL) { if ((unsigned) pw->pw_uid >= uid_allocated) { unsigned new_allocated = (unsigned) pw->pw_uid + ALLOC_STEP; uid_unused = xrealloc (uid_unused, new_allocated); memset (uid_unused + uid_allocated, 1, new_allocated - uid_allocated); uid_allocated = new_allocated; } uid_unused[(unsigned) pw->pw_uid] = 0; } endpwent ();
In shell script, this would be equivalent to, "getent passwd" which could be called from XCCDF. It could also create a huge user listing. But the output of that could be run through the regex.
-Steve
On Tuesday, July 23, 2013 04:04:16 PM Steve Grubb wrote:
On Tuesday, July 23, 2013 03:30:45 PM Steve Grubb wrote:
I'd also be curious if the find command gets it right.
setpwent (); while ((pw = getpwent ()) != NULL) { if ((unsigned) pw->pw_uid >= uid_allocated) { unsigned new_allocated = (unsigned) pw->pw_uid + ALLOC_STEP; uid_unused = xrealloc (uid_unused, new_allocated); memset (uid_unused + uid_allocated, 1, new_allocated - uid_allocated); uid_allocated = new_allocated; } uid_unused[(unsigned) pw->pw_uid] = 0; } endpwent ();
In shell script, this would be equivalent to, "getent passwd" which could be called from XCCDF. It could also create a huge user listing. But the output of that could be run through the regex.
After checking the OVAL specification, openscap source code, and getpwent man page, It looks like you can build the OVAL variable from the password_test. USGCB takes the simplistic approach of directly parsing the password file. But you should be able to switch from the file test to password test.
-Steve
scap-security-guide@lists.fedorahosted.org