12:11 p.m.
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
12:52 p.m.
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(a)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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
8:27 p.m.
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(a)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.... ;)
7:59 a.m.
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.... ;)
12:17 p.m.
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(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(a)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.... ;)
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
12:53 p.m.
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(a)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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
1:04 p.m.
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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
1:19 p.m.
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
1:24 p.m.
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
1:49 p.m.
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
2:10 p.m.
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?
2:30 p.m.
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
2:47 p.m.
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
3:31 p.m.
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(a)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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
3:44 p.m.
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(a)lists.fedorahosted.org
[scap-security-guide-bounces(a)lists.fedorahosted.org] on behalf of Andrew Gilmore
[agilmore2(a)gmail.com]
Sent: Tuesday, July 23, 2013 4:31 PM
To: scap-security-guide(a)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.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
4:12 p.m.
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(a)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(a)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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
4:16 p.m.
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(a)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(a)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(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
11:31 a.m.
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...
Tomas
12:24 p.m.
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...
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
2:52 p.m.
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...
Tomas
3:04 p.m.
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
4:04 p.m.
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
3909
days inactive
3928
days old
scap-security-guide@lists.fedorahosted.org
22 comments
7 participants
participants (7)
-
Andrew Gilmore -
Gary Gapinski -
Maura Dailey -
Robert Sanders -
Shawn Wells -
Steve Grubb -
Tomas Heinrich