Hello Radzy, thank you for checking.
----- Original Message ----- > From: "T Radzykewycz (Radzy)" <[email protected]> > To: [email protected] > 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 <[email protected]> > > Subject: Re: investigating "notapplicable" > > To: SCAP Security Guide <[email protected]> > > > > 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.xml and * [2] https://github.com/OpenSCAP/openscap/blob/maint-1.2/cpe/openscap-cpe-oval.xml 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, <[email protected]> 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 > > > [email protected] > > > > > > https://lists.fedorahosted.org/admin/lists/[email protected] > > > https://github.com/OpenSCAP/scap-security-guide/ > -- > SCAP Security Guide mailing list > [email protected] > https://lists.fedorahosted.org/admin/lists/[email protected] > https://github.com/OpenSCAP/scap-security-guide/ > -- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected] https://github.com/OpenSCAP/scap-security-guide/
