Hello Radzy,
thank you for checking.
----- Original Message -----
From: "T Radzykewycz (Radzy)" <radzy(a)windriver.com>
To: scap-security-guide(a)lists.fedorahosted.org
Sent: Thursday, July 14, 2016 4:26:36 PM
Subject: Re: investigating "notapplicable"
________________________________________
> Date: Mon, 11 Jul 2016 13:06:35 -0600
> From: Gabe Alford <redhatrises(a)gmail.com>
> Subject: Re: investigating "notapplicable"
> To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org>
>
> Hello Radzy,
>
> > I'm trying to figure out how to go about investigating why
> > "notapplicable"
> > is returned. Mostly, I'm working with a new directory for WR Linux.
>
> Are you saying that all checks return "notapplicable" when you run a
scan?
> Or are you saying that you created a custom OVAL and the OVAL itself is
> returning "notapplicable"?
Hi Gabe
When I tested the four commented-out rules on Fedora, there were
a mix of notapplicable, pass, and fail.
On WRLinux, all checks return "notapplicable". I wonder whether
this might have been caused by a change I didn't make in OpenSCAP
and should have.
IMHO the source of this confusion is current a bit unfortunate use
of 'notapplicable' result to indicate two different system conditions:
* In most general case 'notapplicable' result is used to indicate the
benchmark intended for one product (defined by list of CPEs within it)
was used to scan system not compatible with that CPE (like in your case
Fedora benchmark expecting Fedora 22 up to Fedora 25 CPEs to be present)
was used to scan WR Linux system (which I assume provides different CPE
definitions). If you wanted properly to use the Fedora benchmark on WR Linux
system, the benchmark would need to be extended with that CPE list for WR Linux.
* As already suggested by Zbynek in previous reply, 'notapplicable' result is
used
by oscap also in different scenario - namely in effort to scan Docker image in
offline mode (not a running container). In this scenario 'notapplicable' result
is returned for probes (think of them like children of the oscap process responsible
to retrieve subinformation from the system like e.g. content of the text file, or
permissions of specific file) that are recognized not to work properly in offline
mode. To mention a specific example of such a probe, the sysctl probe won't return
proper results when scanning (not running) Docker image for some sysctl property
being present. This is due to limitation it's not possible to obtain content of
specific /proc FS entry, when the system isn't running. And there are more such
probes,
we currently know don't work properly when scanning offline images. In this case
the probe will also report 'notapplicable' as a result of the system's
property
scan.
On the other hand as soon as the Docker image runs, or it's a live system,
the probe will work correctly (is able to obtain the necessary information),
and thus will return appropriate result ('pass' or 'fail').
So to explain the aforementioned behaviour - when scanning Fedora offline
image, there's a mixture of 'pass', 'fail', and
'notapplicable' results. In
this case the 'notapplicable' means the probe wasn't able to collect the
status
of the particular system property (there might be more appropriate state though
to indicate this like e.g. 'unknown' [primary result for the OVAL unknown_test],
or 'error' [primary result when OVAL definition uses multiple variables to
retrieve
the result, and the scanner wasn't able to collect the value of some variable on
the path, thus can't continue to provide sophisticated result, and reports
'error'].
We might change this behaviour in the future, as soon as we find a more appropriate
state, that will be unambiguous enough). But in this case the CPE in the benchmark
matched (IOW benchmark intended for the product was used to truly scan that product).
But when scanning WR Linux with Fedora benchmark, not only issue with the probes
happens, but already use case #1 happens (IOW the list of CPEs in the Fedora benchmark
doesn't allow to scan WR Linux). In this case all rules will return
'notapplicable'
to indicate this (this case has nothing to do with offline probes implementation status).
But I haven't been able to figure out where the
current CPE is determined.
It's determined natively by oscap (when the CPE is present in its internal
dictionary, see:
* [1]
https://github.com/OpenSCAP/openscap/blob/maint-1.2/cpe/openscap-cpe-dict... and
* [2]
https://github.com/OpenSCAP/openscap/blob/maint-1.2/cpe/openscap-cpe-oval...
for the currently known definitions).
But it can be provided also via --cpe argument to the oscap executable / scanner
directly on the command line.
But I expect the "how do I" question
to be relevant when I get a mix of responses, too.
To be able to use the Fedora benchmark on WR Linux you need to:
* modify the Fedora benchmark "ssg-fedora-xccdf.xml" /
"ssg-fedora-ds.xml"
and add the CPEs for WR Linux into list of <platform> elements:
<platform idref="cpe:/o:fedoraproject:fedora:25" />
<platform idref="cpe:/o:fedoraproject:fedora:24" />
...
<platform idref="cpe/o:add_WR_Linux_CPE_here" />
* and provide custom WR Linux CPE dictionary via --cpe oscap argument,
since WR Linux so far isn't supported by oscap yet (IOW oscap doesn't
contain CPE definitions for WR Linux yet [1] [2])
I did create a custom OVAL, but as far as I can tell, it was
never checked.
See above for explanation why.
Hope the above being helpful.
Regards, Jan
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
>
> Enjoy!
>
> -- radzy
>
> > Thanks,
> >
> > Gabe
> >
> > On Mon, Jul 11, 2016 at 12:15 PM, <radzy(a)windriver.com> wrote:
> >
> > > Hi folks
> > >
> > > I'm trying to figure out how to go about investigating why
> > > "notapplicable"
> > > is returned. Mostly, I'm working with a new directory for WR Linux.
> > >
> > > However, I also see that for Fedora, there are four rules that are
> > > commented out with a comment:
> > >
> > > The following rules currently returns 'notapplicable' on
Fedora
> > > container
> > > Investigate why, fix the issues, and re-enable back once fixed
> > >
> > > The specific rules that are commented out are:
> > >
> > > accounts_password_all_shadowed
> > > root_path_no_dot
> > > mount_option_dev_shm_nodev
> > > mount_option_dev_shm_nosuid
> > >
> > > When I tried to reproduce this, I find that
> > > accounts_password_all_shadowed
> > > passes on a vanilla Fedora 23 installation. Maybe it's different on a
> > > container-based install than on an install on a plain old laptop.
> > >
> > > root_path_no_dot appears to be malformed, with various pieces missing.
> > >
> > > The other two don't show up in my output results at all. Not sure
why.
> > > They do appear to be present in the DS file, and I haven't yet found
any
> > > reason to consider them malformed.
> > >
> > > But my general question is about the procedure to go about this
> > > investigation. Is there a document that gives hints about the
> > > best way to do this ? I've looked for one, but haven't found it.
> > > What I've done so far is largely manual, and it has been somewhat
> > > awkward getting the results. (Mostly, I've tried to investigate
> > > WR Linux, but the Fedora issues seemed like a good thing to use
> > > for more experience.)
> > >
> > > Any help would be appreciated.
> > >
> > > Enjoy!
> > >
> > > -- radzy
> > > --
> > > SCAP Security Guide mailing list
> > > scap-security-guide(a)lists.fedorahosted.org
> > >
> > >
https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedo...
> > >
https://github.com/OpenSCAP/scap-security-guide/
> --
> SCAP Security Guide mailing list
> scap-security-guide(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedo...
>
https://github.com/OpenSCAP/scap-security-guide/
>