On Tuesday, April 22, 2014 11:16:31 AM Renshaw, Richard /c wrote:
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.
libexec is for executables that should not be called directly. I think files in
that directory should be checked following the same rules as /(s)bin or
/usr/(s)bin. The library checks should apply to /lib(64), /usr/lib(64) and
possibly /usr/local/lib(64). I think in both cases it should be recursive,
just in case.
-Steve
> On Apr 22, 2014, at 11:05 AM, "Jan Ruzicka"
> <jan.ruzicka(a)comtechmobile.com> wrote:
> 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=55b5
>> ec008650ead4249edc6305196326aa09b2fd
>> _______________________________________________
>> scap-security-guide mailing list
>> scap-security-guide(a)lists.fedorahosted.org
>>
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
> 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