CCE-27032-2

Shawn Wells shawn at redhat.com
Sat Oct 5 00:57:04 UTC 2013


On 10/4/13 8:46 PM, Jeff Bachtel wrote:
> Ah cool, but that's *no_files_unowned_by_user, *not 
> *world_writable_files_system_ownership *(CCE-26642-9) that I had the 
> false pos on.
>
> I'll try to log in in a few to update the ticket if you're busy.

Hah, whoops. *I* was looking at the 
dir_perms_world_writable_system_owned check. Either way, it's the same 
process to see what's up.

For CCE-27032-2/no_files_unowned_by_user, it's the same story... the 
OCIL needs to be updated.

[shawn at SSG-RHEL6 checks]$ sudo find / -xdev -nouser -print
[shawn at SSG-RHEL6 checks]$ ./testcheck.py no_files_unowned_by_user.xml
Evaluating with OVAL tempfile : /tmp/no_files_unowned_by_userWvvmmI.xml
Writing results to : /tmp/no_files_unowned_by_userWvvmmI.xml-results
Definition oval:scap-security-guide.testing:def:152: false
Evaluation done.
[shawn at SSG-RHEL6 checks]$ vim ^C
[shawn at SSG-RHEL6 checks]$ grep -4 system_data 
/tmp/no_files_unowned_by_userWvvmmI.xml-results
           <object id="oval:scap-security-guide.testing:obj:154" 
version="1" flag="complete">
             <reference item_ref="1105751"/>
           </object>
         </collected_objects>
         <system_data>
           <unix-sys:file_item id="1105751" status="exists">
<unix-sys:filepath>//.autofsck</unix-sys:filepath>
             <unix-sys:path>/</unix-sys:path>
<unix-sys:filename>.autofsck</unix-sys:filename>
--



I updated the ticket to review *all* the OCIL checks. A few of us are on 
#ssg on freenode tonight, and actively developing (so will be on the 
list) until late EST





>
>
> On Fri, Oct 4, 2013 at 8:32 PM, Shawn Wells <shawn at redhat.com 
> <mailto:shawn at redhat.com>> wrote:
>
>     On 10/4/13 8:28 PM, Shawn Wells wrote:
>
>         On 10/4/13 8:13 PM, Jeff Bachtel wrote:
>
>             I keep getting a fail on CCE-27032-2, even after
>             rebuilding SSG from master. The bad thing is that find /
>             -nouser and find / -nogroup are not finding whatever files
>             are triggering the warning.
>
>             Is there a debug flag I should be using for more details
>             from oscap to track this down?
>
>
>         The failure should be in your results file. Since you're using
>         source:
>
>         [shawn at SSG-RHEL6 checks]$ pwd
>         /var/www/html/scap-security-guide/RHEL6/input/checks
>
>         [shawn at SSG-RHEL6 checks]$ sudo find / -xdev -type d -perm 0002
>         -uid +500 -print
>
>         [shawn at SSG-RHEL6 checks]$ ./testcheck.py
>         dir_perms_world_writable_system_owned.xml
>         Evaluating with OVAL tempfile :
>         /tmp/dir_perms_world_writable_system_owneddqzNLB.xml
>         Writing results to :
>         /tmp/dir_perms_world_writable_system_owneddqzNLB.xml-results
>         Definition oval:scap-security-guide.testing:def:148: false
>         Evaluation done.
>
>         Open your results file and check what's in the system_data
>         area. It'll indicate what files/dirs are causing the fail. On
>         mine:
>
>         [shawn at SSG-RHEL6 checks]$ grep -4 system_data
>         /tmp/dir_perms_world_writable_system_owneddqzNLB.xml-results
>                   <object
>         id="oval:scap-security-guide.testing:obj:150" version="1"
>         flag="complete">
>                     <reference item_ref="1104981"/>
>                   </object>
>                 </collected_objects>
>                 <system_data>
>                   <unix-sys:file_item id="1104981" status="exists">
>                     <unix-sys:path>/test</unix-sys:path>
>                     <unix-sys:filename></unix-sys:filename>
>                     <unix-sys:type>directory</unix-sys:type>
>         -- 
>
>
>         Clearly the find command needs updating though
>
>     To ensure updating the find command doesn't get forgotten about:
>     https://fedorahosted.org/scap-security-guide/ticket/417
>
>     .... whoever feels ambitious to take that ticket, please do so!
>
>     _______________________________________________
>     scap-security-guide mailing list
>     scap-security-guide at lists.fedorahosted.org
>     <mailto:scap-security-guide at lists.fedorahosted.org>
>     https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>
>
>
>
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide


-- 
Shawn Wells
Director, Innovation Programs
shawn at redhat.com | 443.534.0130
@shawndwells

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20131004/7c6ccfb9/attachment.html>


More information about the scap-security-guide mailing list