Hello All,

I'm working back through the way several SCAP processing tools handle the rpmverifyfile object and come upon some confusion.  Let me describe the way our tool (SCC) approaches this and see if our understanding of the object processing makes sense.

We use the rpm command to pull back most fields used by the rpmverifyfile item, like:

However, the file attributes aren't easily gathered in that first pull.  So, for each package identified, we use the '-vV'  to gather the file list and attributes for the files provided by each package.  Like:

We compare the package details against the rpmverifyfile_object elements, determine which packages should yield items, and create items.

The confusion I'm running into has to do with the file list for each package (rpm).  It is our position that items should be created only for those filepaths that are provided by the actual package (rpm -vV).  There can be other files that an installed rpm may end up using, but, we assert that those files are outside the scope of the rpmverifyfile test and should not be represented as items.

Am I missing anything, here?

Thanks

John R. Ulmer
SPAWAR Systems Center Atlantic
john.r.ulmer6.civ@mail.mil
843.218.5953

...

On 4/18/17 3:20 PM, Ulmer, John R CIV USN SPAWARSYSCEN LANT SC (US) wrote:

Makes sense to me. An example we (Red Hat) recently ran into was
/etc/httpd/conf.d/* files. The httpd RPM does create the conf.d
directory, however an rpm verify will not evaluate
/etc/httpd/conf.d/my_custom_modules.conf.

I'd follow the OS-level RPM verify process of only verifying
natively-included files in the RPM itself.

For reference, the OpenSCAP rpmverifyfile probe:
https://github.com/OpenSCAP/openscap/blob/maint-1.2/src/OVAL/probes/unix/linux/rpmverifyfile.c

And sample OVAL:
https://github.com/OpenSCAP/scap-security-guide/blob/master/shared/oval/rpm_verify_permissions.xml

...

On Tuesday, April 18, 2017 3:20:28 PM EDT Ulmer, John R CIV USN SPAWARSYSCEN
LANT SC (US) wrote:

item, like:

The -vV command is a verify command. I don't think that is the best way to get
the list of expected file/directory attributes.

The way that I fetch the file information for scripting is like this:

rpm -q --dump $package

and

rpm -q --qf "[%{filenames}\t%{fileflags:fflags}\n]"  $package

This second query will give you information about what the file is. A 'd'
means directory, 'g' ghost, 'cn' mean configuration file and no-erasing.

Substitute --dump and I agree. However, note that sometimes you get
verification information for ghost files.

s/using/generating

Sometimes you do have verification information for ghosted files. For example,
look at this one:

/etc/X11/XvMCConfig 0 1475670102
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 0100644 root
root 1 0 0 X

The size is 0 which means its ghosted. However, should it exist, the
permissions are expected to be 0644 root root.

-Steve

...

On Tuesday, April 18, 2017 3:39:34 PM EDT Shawn Wells wrote:

item, like:

So, for each package identified, we use the '-vV'  to gather the file list and
attributes for the files provided by each package.  Like:

my_custom_modules.conf is not likely to be packaged. But if it were, then
you'd have the information and you have to check it. For example, httpd does
put a couple in that directory and they do have to be evaluated:

/etc/httpd/conf.d/autoindex.conf 2926 1492031004
339f0a6bc069226a00671689531c12727324b465cabab9c519df3641cbd9a81e 0100644 root
root 1 0 0 X
/etc/httpd/conf.d/userdir.conf 1252 1492005043
7e3e5b4f171425adcd259788d2cf1ae3fecad9b914a3e1cc92b70a2b75b1e8e0 0100644 root
root 1 0 0 X
/etc/httpd/conf.d/welcome.conf 824 1492005043
08283cb45c8a5066e75622b60bc8725b4b6df07d7b95ecd4b8cb2e8b436860e5 0100644 root
root 1 0 0 X

The idea is not that everything in  /etc/httpd/conf.d/* should be verified.
It's if we have verification information on them then they must be checked.

The central issue that confuses people is what do you do about ghosted files.
These are files that are not shipped but may or may not exist (they are
normally created by a program running). For any file that is non-zero in size,
it should exist on the filesystem and be verified. If it is zero in size, it
should be checked for and verified only if it exists.

-Steve

...