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" > > <[email protected]> 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 > >> [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 _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
