attempt fix broken file_permissions_ungroupowned.xml

Rodney L. Mercer rmercer at harris.com
Tue May 6 13:55:56 UTC 2014


On Mon, 2014-05-05 at 23:53 -0400, Shawn Wells wrote:
> On 5/1/14, 8:33 AM, Rodney L. Mercer wrote:
> > I am attempting to modify the completely broken
> > file_permissions_ungroupowned.xml with essentially the same logic that I
> > had used to fix the previously completely broken
> > no_files_unowned_by_user.xml
> >
> > It seemed to me that it would be a simple task, and for the most part, I
> > believe that it is.
> >
> > There is just one issue that I cannot seem to overcome, and hopefully
> > one of you can help identify the problem.
> >
> > The attached code works to find files that have gids that are not found
> > in /etc/group. The problem is that if the gid is 12 which maps to mail,
> > it flags it as a fail? The only valid gid that I can find that fails is
> > gid 12? So, any mail file in /var/spool/mail and the symlink /var/mail
> > shows up as a failure?
> >
> > chgrp these files to another valid group and no failures occur.
> >
> > Any help debugging this is appreciated.
> >
> > Thanks,
> >
> > Rodney.
> 
> Dave Smith and I were instant messaging this morning about the backup of 
> EMails. While I didn't acknowledge this on-list, I've been tinkering on 
> the patch and having crazy results...
> 
> In short, I'm actually getting an OpenSCAP error from your code (which 
> takes ~8-10min to occur on a 2GB, 2x1.7GHz VM across a 2.5GB filesystem!):
> > $ ./testcheck.py file_permissions_ungroupowned.xml
> > Evaluating with OVAL tempfile : 
> > /tmp/file_permissions_ungroupownedJB4bvk.xml
> > Writing results to : /tmp/file_permissions_ungroupownedJB4bvk.xml-results
> > OpenSCAP Error: Unable to close probe sd [oval_probe_ext.c:565]
> 
> (1) If I run the existing OVAL, it fails within a few seconds.
> (2) If I then run your patch, it errors after 8-10min as shown above.
> (3) If I then re-run the existing OVAL, I get the same OpenSCAP error.
> (4) If I then reboot, I can re-run the existing OVAL, but still get the 
> OpenSCAP error on your code.
> 
Hmmm, I'm not seeing the behavior you are describing. I just created
another VM RHEL6.4 and git cloned scap-security-guide.
When I ./testcheck.py file_permissions_ungroupowned.xml, it fails and
the result shows /.autofsck as the failure. In fact, if you have any dot
files in / it would flag them as failures. That is all the code does.
[root at server1 checks]# grep -A4
system_data /tmp/file_permissions_ungroupownedcYywR9.xml-results
        <system_data>
          <unix-sys:file_item id="1120301" status="exists">
            <unix-sys:filepath>//.autofsck</unix-sys:filepath>
            <unix-sys:path>/</unix-sys:path>
            <unix-sys:filename>.autofsck</unix-sys:filename>
--

Copying in my patch and rerunning, I see a bit more now than I
previously described. I need to dig a little deeper it seems.

See below.


[root at server1 checks]# egrep
"unix-sys:filepath" /tmp/file_permissions_ungroupownedUKV77w.xml-results
            <unix-sys:filepath>/var/run/cups/certs/0</unix-sys:filepath>

<unix-sys:filepath>/var/cache/cups/job.cache</unix-sys:filepath>
            <unix-sys:filepath>/var/mail/root</unix-sys:filepath>
            <unix-sys:filepath>/var/mail/mike</unix-sys:filepath>
            <unix-sys:filepath>/var/mail/rpc</unix-sys:filepath>
            <unix-sys:filepath>/var/spool/mail/root</unix-sys:filepath>
            <unix-sys:filepath>/var/spool/mail/mike</unix-sys:filepath>
            <unix-sys:filepath>/var/spool/mail/rpc</unix-sys:filepath>
            <unix-sys:filepath>/usr/bin/lockfile</unix-sys:filepath>
            <unix-sys:filepath>/usr/bin/procmail</unix-sys:filepath>
            <unix-sys:filepath>/etc/cups/client.conf</unix-sys:filepath>
            <unix-sys:filepath>/etc/cups/lpoptions</unix-sys:filepath>
            <unix-sys:filepath>/etc/cups/cupsd.conf</unix-sys:filepath>
            <unix-sys:filepath>/etc/cups/snmp.conf</unix-sys:filepath>

<unix-sys:filepath>/etc/cups/classes.conf</unix-sys:filepath>

<unix-sys:filepath>/etc/cups/printers.conf</unix-sys:filepath>

<unix-sys:filepath>/etc/cups/subscriptions.conf</unix-sys:filepath>

<unix-sys:filepath>/etc/cups/cupsd.conf.default</unix-sys:filepath>
            <unix-sys:filepath>/var/spool/at/.SEQ</unix-sys:filepath>

[root at server1 checks]# ls -al /var/spool/at/.SEQ
-rw-------. 1 daemon daemon 6 Apr 22 10:56 /var/spool/at/.SEQ
[root at server1 checks]# ls -al /etc/cups/cupsd.conf
-rw-r-----. 1 root lp 4064 Nov  6  2012 /etc/cups/cupsd.conf
[root at server1 checks]# ls -al /var/spool/mail/rpc
-rw-rw----. 1 rpc mail 0 Apr 22 05:55 /var/spool/mail/rpc
[root at server1 checks]# ls -al /etc/cups/classes.conf
-rw-------. 1 root lp 0 Nov  6  2012 /etc/cups/classes.conf


> Looping in our allies within the OpenSCAP community. Peter/Martin/Simon, 
> any idea what could cause the OpenSCAP error?
> 
> 
> Also copying your patch in-line for those following along at home:
> > <def-group>
> >   <definition class="compliance" id="file_permissions_ungroupowned" 
> > version="1">
> >     <metadata>
> >       <title>Find files unowned by a group</title>
> >       <affected family="unix">
> >         <platform>Red Hat Enterprise Linux 6</platform>
> >       </affected>
> >       <description>All files should be owned by a group</description>
> >       <reference source="rmercer" ref_id="20140430" 
> > ref_url="test_attestation" />
> >     </metadata>
> >     <criteria>
> >       <criterion comment="Check all files and make sure they are owned 
> > by a group" test_ref="test_file_permissions_ungroupowned" />
> >     </criteria>
> >   </definition>
> >
> >   <unix:file_state id="file_permissions_unowned_groupid_list_match" 
> > version="1">
> >     <unix:group_id var_check="only one" 
> > var_ref="file_permissions_unowned_groupid_list" datatype="int" />
> >   </unix:file_state>
> >
> >   <local_variable id="file_permissions_unowned_groupid_list" 
> > comment="List of valid group ids" datatype="int" version="1">
> >     <object_component item_field="subexpression" 
> > object_ref="file_permissions_unowned_groupid_list_object" />
> >   </local_variable>
> >
> >   <ind:textfilecontent54_object 
> > id="file_permissions_unowned_groupid_list_object" version="1">
> >     <ind:filepath>/etc/group</ind:filepath>
> >     <ind:pattern operation="pattern 
> > match">^[^:]+:[^:]+:([\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_groupid_object" version="1">
> >     <unix:behaviors recurse="symlinks and directories" 
> > recurse_direction="down" recurse_file_system="local" />
> >     <unix:path>/</unix:path>
> >     <unix:filename operation="pattern match">.*</unix:filename>
> >     <filter 
> > action="exclude">file_permissions_unowned_groupid_list_match</filter>
> >   </unix:file_object>
> >
> >   <unix:file_test 
> > xmlns:unix="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix"
> >   check="all" check_existence="none_exist" comment="Check for files 
> > with no group owner on all files on the system"
> >   id="test_file_permissions_ungroupowned" version="1">
> >     <unix:object object_ref="file_permissions_unowned_groupid_object" />
> >   </unix:file_test>
> > </def-group>
> 
> 
> 
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide



More information about the scap-security-guide mailing list