[SRU][xenial] Enable SCE option and systemd probe in libopenscap8

[Joy Latten]

[Impact]

Canonical security certification team is automating Ubuntu specific security hardening guides using Security Content Automation Protcol (SCAP). SCAP requires Open Vulnerability and Assessment Language (xccdf and xml) to implement SCAP content.

The openSCAP implementation processes SCAP content, but has been extended to also process python and bash scripts via a Script Check Engine (SCE). This ability to process bash and python scripts is needed because OVAL is somewhat limited in what it can do. We have had to write a few python and bash scripts.

SCE is not enabled by default, and will require the addition of the "--enable-sce" option in the "debian/rules" file to turn it on.

There are security hardening rules for systemd. There is also OVAL schema implemented as "probes" in openSCAP. The systemd probe to be enabled requires libdbus-1-dev during build. This would be set in the debian/control file

The attached patch has all the necessary code change.

These 2 changes were made in more current versions of libopenscap8 in Debian as indicated above. As a result, Artful, Bionic and Cosmic also have these changes. The automation we are working on is required for Xenial though.

[Test Case]

1. run the command "oscap --v", and should see following with SEC option enabled,

   ==== Capabilities added by auto-loaded plugins ====
   SCE Version: 1.0 (from libopenscap_sce.so.8)

without the SCE option enabled, the list of plugins is empty.

Also, should see under "==== Supported OVAL objects and associated OpenSCAP probes ===="

systemdunitproperty probe_systemdunitproperty
systemdunitdependency probe_systemdunitdependency

2. The second testcase requires running our SCAP content and verifying that those rules using scripts are run and those rules using systemd probes are run.

[Regression Potential]

The regression potential should be small. The changes proposed enables new functionality that is already included in the source package, and does not change the behavior of existing functionality.

[Joy Latten (j-latten)]

This bug is to enable 2 options available in the libopenscap8 source. Both of these options have been enabled in artful, bionic and cosmic. Both options have also been enabled in Debian via the following Debian bugreports,

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853995
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852826

There are 2 Debian bugs, but I was able to add only 1 above. Since these are small changes, I am hoping one Ubuntu bug will be ok. If not, I can open another bugreport.

Prior bugs, https://bugs.launchpad.net/ubuntu/+source/openscap/+bug/1658792 AND https://bugs.launchpad.net/ubuntu/+source/openscap/+bug/1661401 were opened to address this. The original bugreporter is no longer available. I would like to duplicate those to this bug and use this one to address and resolve this issue.

[Joy Latten (j-latten)]

build log: https://launchpad.net/~j-latten/+archive/ubuntu/joyppa/+build/15137237

[Joy Latten (j-latten)]

Testcases: The testcases included with the libopenscap8 source are disabled. It appears they do not all compile or run correctly, thus disabled. To test this I did the following:

1. oscap --v
Shows that SCE plugin has been enabled and also that the 2 systemd probes have
been enabled.
(See attachment)

2. Our SCAP content for those rules using SCE or systemdprobes now run and also pass.

Rule 1.1.21 uses the systemdunitdependency probe to check that autofs is disabled. This check now passes with the systemd probes enabled.

Title Disable Automounting
Rule xccdf_com.ubuntu.xenial.cis_rule_CIS-1.1.21
Result pass

Rule 6.2.9 uses a script to check that users own their home directory.
Title Ensure users own their home directories
Rule xccdf_com.ubuntu.xenial.cis_rule_CIS-6.2.9
Result pass

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Joy Latten (j-latten)]

libopenscap8 in bionic contains the changes requested in this SRU for xenial. Thus bionic and cosmic do not require this change since already done.

[Marc Deslauriers (mdeslaur)]

ACK on the debdiff in comment #4, looks good. Uploaded for processing by the SRU team with some slight changelog adjustments. Thanks!

[Robie Basak (racb)]

Hi Joy,

From the statement:

"The changes proposed enables new functionality that is already included in the source package, and does not change the behavior of existing functionality."

Is it correct for me to infer that existing users won't see any changes in behaviour following this SRU if they aren't aware of this proposed change? I think this is a subtly different question from the statement above, because it's a question of defaults and default behaviour, rather than what functionality is provided.

For example: is it possible that the addition of new checks would cause a system that previously passed an assessment to fail following this SRU because new checks that happen to fail on some existing system have been added? Or is it that all new functionality added by this change will have to be explicitly opted in to by the user? I'm not sure I fully understand how users use this package so this question may not make exact sense, but I hope you can follow the sort of regression I'm looking for.

[Joy Latten (j-latten)]

Hi Robie,

Yes, you are correct.

This SRU enables 2 things. First, it enables systemd probes/schema. The user would have to have oval code that implements this schema/probe for it to be used. So, several things are likely: 1. users did not implement code using this schema since it was unavailable. 2. if there were codes using this schema, and they were not commented out, the results probably came back "unknown" since it was not available.
Enabling this systemd probe/schema, users with #1 scenario will not notice anything. users with #2 scenario will now have those particular checks come back with "pass" or "fail" instead of "unknown".

The 2nd thing it enables is the script-check-engine (SCE), which allows oscap to include bash or python scripts to assist in scans/checks. The xccdf/xml code has to explicitly call a particular script. And the script would have had to been written for the xccdf. So several things are likely: 1. user's implemented xccdf code without using this feature since it is not available. These users won't see any change when this is enabled. 2. user's xccdf code does call particular scripts. As of now, these checks will always result in a "notchecked" since SCE is not there. When this feature is enabled, for these users, the check will then come back as "pass" or "fail" instead of "notchecked".

In all these scenarios, existing checks that do not implement sce or systemd schemas will continue as they always have and will not be impacted.

Hopefully this is all ok?

[Łukasz Zemczak (sil2100)]

I have been asked to give a second opinion regarding this SRU and I must say my feelings are a bit mixed.

On one side: I have to agree with Robie that this SRU might confuse existing users, those that would otherwise expect some checks coming back with "unknown" or "notchecked" to suddenly start failing. That might regress existing users in a sense, and that is bad.

On the other hand, both SCE and systemd probes/schema were not available nor supported for xenial before, right? Deliberately using functionality that's not supported and relying on it to return an ambiguous state at the end is not valid use IMO. I think it will be quite obvious for anyone using unsupported functionality and relying on it to stay as "unknown"/"notchecked" that eventually those might just start actually running. I think we should not really care about cases of such assumptions, since I somehow feel the developer was not doing the right thing anyway. We can't handle all use-cases. It's still a regression, yes, but a regression that most probably is caused by invalid use. Am I wrong?

Sure, this might be a problem for 'backport' cases, where there's the same check-set for different series, but since there was obviously a difference in functionality between one version an the other, the developer should have handled this better.

That being said, I do not have a strong opinion here. It's really hard to say what's the best way to go as I don't know how many users are there of openscap. I'm probably lacking that context to be able to give a solid answer. Regressing users is bad, but even normal, non-feature bugfixes can 'regress' people that are depending on the erroneous behavior.
I do remember one case handled by a more experienced SRU member that also involved slight regression of functionality for users that didn't use the package properly and the decision was to accept it. Not sure exactly if we have the same case here though. Somehow it does feel like it, but maybe I lack context here as well.

[Joy Latten (j-latten)]

I agree with the above analysis.

There is something else I have noticed... the openscap community consists of several components, one of them implements security-guides (scap content (checklists) to pass to oscap). xenial did not ship any security-guide component. However, bionic does. Bionic also includes the above mentioned changes.

In the past year the openscap community has made many improvements to the security-guides including creating a small checklist specifically for ubuntu-16.04. Bionic ships the security-guides in several packages,
   - ssg-debderived (contains ubuntu-16.04 checklist)
   - ssg-nondebian (contains rhel and sles checklists)
   - ssg-debian (contains debian checklist)

It is possible ubuntu users will try several things using the ssg-debderived package
  - take the ubuntu-16.04 checklist file and try to run it on a xenial system
    However, there are systemd checks in this xccdf. It is possible a bugreport will be generated.

  - try to run the ubuntu-16.04 checklists file on bionic.
    This will fail because checklist file first looks to verify is a 16.04 system. A savvy user can modify the xccdf (checklist file) to recognize 18.04.

[Robie Basak (racb)]

Thanks to Łukasz for a second opinion. I think your points are quite convincing, and I'm inclined to accept the SRU now. I wondered if it was within the SRU's remit to make this decision, but as you point out all fixes are regressions for people relying on broken behaviour, so think that making that decision is an SRU team judgement call now.

Łukasz confirmed on IRC.

[Robie Basak (racb)]

Hello Joy, or anyone else affected,

Accepted openscap into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/openscap/1.2.8-1ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Joy Latten (j-latten)]

Hi Robie,

I tested this SRU with the new package in proposed and verified.

$ dpkg -l | grep libopenscap8
ii libopenscap8 1.2.8-1ubuntu0.1 amd64 Set of libraries enabling integration of the SCAP line of standards

I ran a few rules in my oval that use the systemd probe and they now come back as passing,

$ sudo oscap oval eval --id oval:com.ubuntu.xenial.cis:def:6400 Ubuntu_16.04_LTS_CIS_Benchmark-oval-sec2.xmlDefinition oval:com.ubuntu.xenial.cis:def:6400: true
Evaluation done.

$ sudo oscap oval eval --id oval:com.ubuntu.xenial.cis:def:6600 Ubuntu_16.04_LTS_CIS_Benchmark-oval-sec2.xml
Definition oval:com.ubuntu.xenial.cis:def:6600: true
Evaluation done.

I ran a few scripts (SCE) and they now pass,

$ ls *.sh
CIS-3.6.2.sh CIS-3.6.3.sh CIS-3.6.5.sh CIS-5.4.1.5.sh CIS-6.2.9.sh

Title Ensure users own their home directories
Rule xccdf_com.ubuntu.xenial.cis_rule_CIS-6.2.9
Result pass

Title Ensure all users last password change date is in the past
Rule xccdf_com.ubuntu.xenial.cis_rule_CIS-5.4.1.5
Result pass

To note any regression, I ran the entire testsuite and saw similar output (other than those that now pass).

I consider this verification for this SRU.

[Launchpad Janitor (janitor)]

This bug was fixed in the package openscap - 1.2.8-1ubuntu0.1

---------------
openscap (1.2.8-1ubuntu0.1) xenial; urgency=medium

  * Enable both systemd probes and SCE. (LP: #1782031)
    - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852826
    - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853995

 -- Joy Latten <email address hidden> Mon, 16 Jul 2018 17:05:18 -0500

[Łukasz Zemczak (sil2100)]

The verification of the Stable Release Update for openscap has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.