[MIR] openscap

Bug #1877696 reported by Seth Arnold
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openscap (Ubuntu)
Ubuntu Security Team

Bug Description

Hello, the Ubuntu Security Team would like to propose the libopenscap8 binary
package from openscap be promoted to main.

libopenscap8 is useful in main for two reasons:

 - The Security team publishes OVAL CVE data, which libopenscap8 is the only package in Ubuntu capable of evaluating this content. This allows users to check whether their system has all available security updates.
 - The Certifications team publishes XCCDF+OVAL content for evaluating various benchmarks (such as CIS and STIG), which again libopenscap8 is the only such package satisfying this usecase in Ubuntu.

We'd like to first rebase to OpenSCAP 1.3.x, as this release will see upstream support longer into the future than the existing OpenSCAP 1.2.x release will. As OpenSCAP is a Red Hat upstream community, and OpenSCAP 1.2.x is shipped in RHEL 7 which is nearing EoL, they have stopped doing feature development work on OpenSCAP 1.2.x and focused on OpenSCAP 1.3.x (which is shipped in RHEL 8 and current Fedora versions). No later version exists at this time. This release is currently present in Debian Testing.

openscap is in universe.

The Ubuntu Security & Compliance Team would like the libopenscap8 binary package from openscap promoted to main. libopenscap8 is referenced in our product documentation and several supported scenarios. Since some customers may not have ESM Apps (and thus LTS universe package support), shipping openscap in universe limits some customers from consuming Canonical-sponsored content, though they may pay for other content and reasonable expect the entire use-case be supported.

As the intention is to use libopenscap8 in security software, it makes sense to require a security review. However, the package is intended to be executed by a local administrator (on content they trust) after using existing permission escalation procedures. libopenscap8 does not ship a daemon (or otherwise persist between runs), does not open any open ports, and does not add any other permission escalation paths (such as suid, sgid, &c).

[Quality Assurance]
- No configuration is necessary to use the library, though applications that use the library will provide content meant to be consumed via this library.
- grep -ri debconf returns no results.
- Upstream bug tracker has many open issues, some security relevant issues open for years.
- The Ubuntu bug tracker has very few open issues; the most important one is a segfault that has been ignored in Debian. The SRU appears stalled:
  - https://bugs.launchpad.net/ubuntu/+source/openscap/+bug/1851682
  However, this is addressed in the proposed OpenSCAP 1.3.x rebase.
- tests are not run (see debian/rules)
- debian/watch exists
- lintian messages:
 E: openscap source: source-is-missing xsl/xccdf-resource/bootstrap.min.js
 E: openscap source: source-is-missing xsl/xccdf-resources/openscap.js
line length is 263 characters (>256)
 W: openscap source: python-foo-but-no-python3-foo python-openscap

(Note: lintian has not been re-run on the proposed OpenSCAP 1.3.x rebase)

All dependencies of the libopenscap8 library are in main. The source
package is less happy:

- dh-python
- python-defaults
- swig

[Standards compliance]
- I didn't spot FHS problems in the libopenscap8 binary package.
- Unknown Debian policy compliance.
- Quilt package

Security team is subscribed to bugs.

[Background information]
SCAP is an assertions language that is popular in the security communities for standardizing data streams. It can be used both for encoding information about vulnerable packages (as our OVAL data currently describes) as well as providing rules to measure compliance with published security standards.


Original author: Seth Arnold
Updated by: Alex Scheel
Revisited: 2021-06-02

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

FYI, snapcraft can build from universe just fine. I suspect what you are seeking is official support so openscap can get security support, therefore USNs, therefore cvescan can get snap USN notifications. In terms of an existing stable release, IIRC it is not possible to adjust the override for something in the release pocket, but that is ok: if this is approved then with the first upload to -security we can adjust the override for that source and binary (we could do the same for an SRU to -updates). In terms of the snap USN service, it doesn't care where the package resides; it just cares that there is a USN.

As for which release, cvescan could certainly be ported to 'base: core20', but as of today, core20 is not released yet (there are snaps, but UC20 (and therefore the core20 snap) hasn't been declared officially released yet, so it probably makes sense to hold off on porting. That said, since it doesn't seem like there are any open CVEs yet so I suggest proceeding with this MIR with groovy and focal in mind and porting later. If you still need core18, I then suggest also going back to bionic.

description: updated
Revision history for this message
Matthias Klose (doko) wrote :

so apparently this package was ftbfs, now fixed by rbalint. Please could you confirm that the package is in the working state?

Changed in openscap (Ubuntu):
status: New → Incomplete
Revision history for this message
Mark Morlino (markmorlino) wrote :

the oscap from libopenscap8 in groovy proposed runs our a sample of our OVAL files without any problems

Changed in openscap (Ubuntu):
status: Incomplete → New
Changed in openscap (Ubuntu):
assignee: nobody → Christian Ehrhardt  (paelzer)
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :
Download full text (4.3 KiB)

MIR Team ack to promote liboepnscap8 and the source (will auto-promote libopensacp-dev).
There are a few suggestions to improve the package (see below), if (ever) more of the package shall be promoted those are s/optional/required/ then.
This does need a security review, so I'll assign ubuntu-security

- Please work on converting python-openscap to python3 (not gating the promotion).
- given the low quality (many open issues) this might cause quite some work, so be suer that you want to own this in Ubuntu
- please consider adding symbols tracking
- how about bumping at least groovy to the latest much newer version 1.3.3?
- new -dbg style?
- adopt debhelper >9

There are no massive differences between the releases. So the request to promote in older releases should be ok if the release and SRU team agrees.
I'm sure the archive admins will know if that is allowed.
Bionic: 1.2.15-1ubuntu0.1
Focal: 1.2.16-2ubuntu3
-dev: 1.2.16-2ubuntu5

There is no other package in main providing the same functionality for SCAP definitions.

- no -dev/-debug/-doc packages that need exclusion
  The one that is packages has no odd dependencies, so no exclusion needed

- other Dependencies to MIR due to this
  - most dependencies are in main already, except one concerning bit
    python-openscap is pure python2
=> That means:
  - you can't promote that binary in >=Focal, do you need it?
    You wrote that you need "libopenscap8" so that might be ok for you
  - Never the less to be safer you should consider working on getting
    it a python3-openscap and drop python-openscap

[Embedded sources and static linking]
- no embedded source present
- no static linking

- history of CVEs does not look concerning
- does not run a daemon as root
  There is src:openscap-daemon, but no one depends on it
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port
- does not process arbitrary web content
  TBH that depends on the user of the lib
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
 - does not deal with system authentication (eg, pam), etc)

- does parse data formats

A quick security review on the data parsing bits of the lib would be good, just so it isn't obviously running into classic parsing/buffer issues and such.
Given that it is from a security background one would hope it is fine, but a quick check can't hurt.

[Common blockers]
- does not FTBFS currently
- The package has a team bug subscriber (ubuntu-security)
- no translation present, but none needed for this case (user visible)?
- Python package that is using dh_python
- Not a Go package that uses dh-golang

- does not have a test suite that runs at build time
- does not have a test suite that runs as autopkgtest
- new python2 dependency

This matches your report of an overall low-medium quality.
You will have to own it once promoted and have to be clear to work on all these issues when affecting Ubuntu users.

[Packaging red flags]
- d/watch is present and looks ok
- Upstream update history is ok, but slow
- Debian/Ubuntu updat...


Changed in openscap (Ubuntu):
assignee: Christian Ehrhardt  (paelzer) → Ubuntu Security Team (ubuntu-security)
Revision history for this message
Evgeny Kolesnikov (evgenyz) wrote :

Just FYI, the newer 1.3 branch has a lot of fixes related to Debian-based distributions, including the test suite, dpkg probe and others. Moreover, this branch is now gated in upstream CI against the latest Ubuntu.

We (OpenSCAP team) tried to contact Debian's maintainer regarding the package upgrade, but there was no response so far.

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Evgeny, thanks for the comment. Ideally the Debian maintainer would bring in the new version, but we can leapfrog them if necessary.


Revision history for this message
Alexander Scheel (cipherboy) wrote :

The MIR text in comment #0 has been updated.

description: updated
description: updated
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers