probe_file taking forever (UNCLASSIFIED)

Trey Henefield trey.henefield at ultra-ats.com
Tue May 20 15:02:48 UTC 2014


I noticed the same thing.

It appears to be affected by 'recurse="symlinks and directories"'.

If that is changed to ' recurse="directories"', it performs much better.

This may be related to a previous discussion regarding behavior of symlinks. It seems like it's going into an endless loop.

https://github.com/OVALProject/Language/issues/107

I also noticed that is does not resolve symlink targets for files either. But I believe that has been an ongoing issue.

Best regards,
 

Trey Henefield, CISSP
Senior IAVA Engineer

Ultra Electronics
Advanced Tactical Systems, Inc.
4101 Smith School Road
Building IV, Suite 100
Austin, TX 78744 USA

Trey.Henefield at ultra-ats.com
Tel: +1 512 327 6795 ext. 647
Fax: +1 512 327 8043
Mobile: +1 512 541 6450

www.ultra-ats.com

-----Original Message-----
From: scap-security-guide-bounces at lists.fedorahosted.org [mailto:scap-security-guide-bounces at lists.fedorahosted.org] On Behalf Of Shaw, Ray V CTR USARMY ARL (US)
Sent: Tuesday, May 20, 2014 9:53 AM
To: scap-security-guide at lists.fedorahosted.org
Subject: probe_file taking forever (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

Using the version of OpenSCAP shipped with RHEL6, and the mostly-latest git content (as of 12 May), checks involving probe_file seem to be taking a lot longer.  Select output of ps faxw below, with the names changed to protect the non-compliant:

19431 ?        S      0:00  \_ /usr/bin/oscap xccdf eval --profile
stig-rhel6-server-upstream --results hostname.example.com_scap_el6.xml --report hostname.example.com_scap_el6.html --cpe /usr/share/xml/scap/ssg/content/ssg-rhel6-cpe-dictionary.xml
/usr/share/xml/scap/ssg/content/ssg-rhel6-xccdf.xml
19445 ?        Sl     0:00      \_ /usr/libexec/openscap/probe_system_info
19450 ?        Sl     0:00      \_ /usr/libexec/openscap/probe_system_info
19455 ?        Sl     0:00      \_ /usr/libexec/openscap/probe_family
19460 ?        Sl     0:01      \_ /usr/libexec/openscap/probe_rpmverifyfile
19647 ?        Sl     0:00      \_ /usr/libexec/openscap/probe_system_info
19653 ?        Sl     0:00      \_ /usr/libexec/openscap/probe_family
19658 ?        Sl     0:01      \_ /usr/libexec/openscap/probe_rpmverifyfile
20459 ?        Sl     0:00      \_ /usr/libexec/openscap/probe_partition
20468 ?        Sl     0:00      \_ /usr/libexec/openscap/probe_rpminfo
20476 ?        Sl     0:00      \_
/usr/libexec/openscap/probe_textfilecontent54
20496 ?        Sl     1:44      \_ /usr/libexec/openscap/probe_rpmverifyfile
62754 ?        Sl     0:00      \_ /usr/libexec/openscap/probe_runlevel
62765 ?        Sl   9553:55      \_ /usr/libexec/openscap/probe_file

I started the scans on ~50 systems yesterday, and only half of them have finished (seems to be the ones with very few files).  It sits on the first of these checks for quite a while, then moves on to sitting on the second one (see in the output, which I redirect to text files):

Title   Ensure No World-Writable Files Exist
Rule    world_writeable_files
Ident   CCE-26910-0
Result  fail

Title   Ensure All Files Are Owned by a User
Rule    no_files_unowned_by_user
Ident   CCE-27032-2

Scans used to complete a lot more quickly (as in, minutes), so I'm not sure what happened.  I didn't catch any messages over the past few days about this; sorry if I missed them, but I'm (naturally) mid-inspection, which is what these are for...

It looks like the *17 release hasn't made it into EPEL yet, or I might try that; there are enough improvements since the 0.1-16 release that I don't want to go back that far.

--
Ray Shaw (Contractor, STG)
Army Research Laboratory
CIO, Unix Support



Classification: UNCLASSIFIED
Caveats: NONE

Disclaimer
The information contained in this communication from trey.henefield at ultra-ats.com sent at 2014-05-20 11:02:51 is confidential and may be legally privileged.
It is intended solely for use by scap-security-guide at lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide at lists.fedorahosted.org you are hereby notified that
any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20140520/98ef7c63/attachment.html>


More information about the scap-security-guide mailing list