Jan, 
Without the trailing / the regex will match any directory starting with /lib, 
/lib64, /usr/lib, or /usr/lib64.  Like the spurious /usr/libexec/ file I was 
running into. Even if the trailing / isn't the correct fix, something needs to 
be changed to fix the regex. 

Sent from my iPhone
Rick Renshaw

> On Apr 22, 2014, at 11:05 AM, "Jan Ruzicka" <[email protected]> 
> wrote:
> 
> Hi
> 
> Should the "library directories" test include subdirectories or just 
> directories themselves?
> The required '/' at the expression end doesn't look right.
> Mentioned directories (/lib, /lib64, /usr/lib, and /usr/lib64) would not 
> match the pattern.
> 
> Jan
> 
>> On Apr 22, 2014, at 11:49, Shawn Wells wrote:
>> 
>> 
>>> On 4/22/14, 11:23 AM, Renshaw, Richard /c wrote:
>>> In my particular case, it would fail the ‘file_ownership_library_dirs’ 
>>> CCE-27424-1, test by finding this file:
>>> 
>>> 528273   12 -rwsr-xr-x   1 abrt     abrt         9904 Aug 13  2013 
>>> /usr/libexec/abrt-action-install-debuginfo-to-abrt-cache
>>> 
>>> Patched ssg-rhel6-oval.xml to include a / at the end of the directory in 
>>> the pattern match
>>> 
>>> --- orig.ssg-rhel6-oval.xml            2014-04-22 10:14:05.181639519 -0500
>>> +++ ssg-rhel6-oval.xml  2014-04-22 10:15:26.376636705 -0500
>>> @@ -10573,13 +10573,13 @@
>>>     </linux:rpminfo_object>
>>>     <unix:file_object comment="library directories" id="oval:ssg:obj:1862" 
>>> version="1">
>>>       <!-- Check that /lib, /lib64, /usr/lib, and /usr/lib64 directories 
>>> belong to user with uid 0 (root) -->
>>> -      <unix:path operation="pattern 
>>> match">^\/lib(|64)|^\/usr\/lib(|64)</unix:path>
>>> +      <unix:path operation="pattern 
>>> match">^\/lib(|64)\/|^\/usr\/lib(|64)\/</unix:path>
>>>       <unix:filename xsi:nil="true"/>
>>>       <filter action="include">oval:ssg:ste:2182</filter>
>>>     </unix:file_object>
>>>     <unix:file_object comment="library files" id="oval:ssg:obj:1863" 
>>> version="1">
>>>       <!-- Check that files within /lib, /lib64, /usr/lib, and /usr/lib64 
>>> directories belong to user with uid 0 (root) -->
>>> -      <unix:path operation="pattern 
>>> match">^\/lib(|64)|^\/usr\/lib(|64)</unix:path>
>>> +      <unix:path operation="pattern 
>>> match">^\/lib(|64)\/|^\/usr\/lib(|64)\/</unix:path>
>>>       <unix:filename operation="pattern match">^.*$</unix:filename>
>>>      <filter action="include">oval:ssg:ste:2182</filter>
>>>     </unix:file_object>
>>> 
>>> 
>>> Verified it passes on my test system.
>>> 
>>> Thanks,
>>> Rick Renshaw
>> 
>> 
>> I'm able to replicate:
>> 
>>> $ sudo ./testcheck.py file_ownership_library_dirs.xml
>>> $ sudo vim /tmp/file_ownership_library_dirs4UFZxe.xml-results 
>>> ......
>>>        <system_data>
>>>          <unix-sys:file_item id="1300351" status="exists">
>>>            
>>> <unix-sys:filepath>/usr/libexec/abrt-action-install-debuginfo-to-abrt-cache</unix-sys:filepath>
>>>            <unix-sys:path>/usr/libexec</unix-sys:path>
>> 
>> As Rick called out, /usr/libexec is artificially being scanned.
>>> $ sudo ./testcheck.py file_ownership_library_dirs.xml 
>>> Evaluating with OVAL tempfile : /tmp/file_ownership_library_dirsKSd7er.xml
>>> Writing results to : /tmp/file_ownership_library_dirsKSd7er.xml-results
>>> Definition oval:scap-security-guide.testing:def:100: true
>>> Evaluation done.
>> 
>> Acking and pushing this patch:
>> https://git.fedorahosted.org/cgit/scap-security-guide.git/commit/?id=55b5ec008650ead4249edc6305196326aa09b2fd
>> _______________________________________________
>> scap-security-guide mailing list
>> [email protected]
>> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> 
> Jan Ruzicka
> Senior Software Engineer
> Comtech Mobile Datacom Corporation
> 20430 Century Blvd, Germantown, MD 20874
> Office: 240-686-3300
> Fax: 240-686-3301
> 
> The information contained in this message may be privileged and/or 
> confidential. If you are not the intended recipient, or responsible for 
> delivering this message to the intended recipient, any review, forwarding, 
> dissemination, distribution or copying of this communication or any 
> attachment(s) is strictly prohibited. If you have received this message in 
> error, please so notify the sender immediately, and delete it and all 
> attachments from your computer and network.
> 
> _______________________________________________
> scap-security-guide mailing list
> [email protected]
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

Reply via email to