[MIR] python-oslo.privsep

[James Page]

[Availability]
In universe

[Rationale]
New dependency for OpenStack projects

[Security]
No security history

[Quality assurance]
Package builds py2 and py3 modules, unit tests run for both.

[Dependencies]
All in main

[Standards compliance]
OK

[Maintenance]
ubuntu-openstack

[Background information]
This library helps applications perform actions which require more or less privileges than they were started with in a safe, easy to code and easy to use manner. For more information on why this is generally a good idea please read over the principle of least privilege and the specification which created this library. (taken from upstream)

[Michael Terry (mterry)]

- Needs a team bug subscriber.

- The subject matter makes me think we should have security look at it real quick.

Otherwise seems fine.

[James Page (james-page)]

subscriber added (ubuntu-openstack team).

[James Page (james-page)]

This is now blocking a number of OpenStack updates for Newton B3 - any chance this can be looked at soon by the security team?

[Seth Arnold (seth-arnold)]

oslo.privsep doesn't appear to be supported by OpenStack VMT. Note the missing vulnerability:managed tag:

https://governance.openstack.org/reference/projects/oslo.html#oslo-privsep

Furthermore, it appears their project configuration doesn't actually alert anyone to private security issues.

This reinforces my feeling that this might not yet be mature enough for deployment. Are we sure this is an actual requirement for OpenStack services? It might eventually be nice but the things I've found so far -- if confirmed to be bugs -- may require careful redesign of some core portions of the library.

Thanks

[James Page (james-page)]

Seth

I'm not to worried about the missing 'vulnerability:managed' tag - there are alot of oslo projects (including the current rootwrap project used for privilege management) that don't have that tag which we know are managed by the VMT.

Corey and I discussed whether this switch is required now - digging on the code to see.

[James Page (james-page)]

The requirement for use of oslo.privsep appears to be limited to nova and cinder use of os-brick (a shared library use to contain the bits and pieces requires to map block devices to instances).

As it stands right now, privsep is initialised by the core compute, volume and backup daemons cross the nova and cinder projects, so unpicking would be tricky this late in the cycle.

[Corey Bryant (corey.bryant)]

This took some work to find the right person to chat with upstream about the 'vulnerability:managed tag'.

tldr: security support is always provided by individual projects regardless of this tag. projects tagged with 'vulnerability:managed' get more strict/rigorous process for their disclosure and reporting.

Here's my chat with Jeremy Stanley <fungi> in #openstack-oslo:

<coreycb> fungi, hi
<coreycb> fungi, I'm looking at this and trying to figure out if only oslo.config gets security support: https://governance.openstack.org/reference/projects/oslo.html#oslo-privsep
<coreycb> fungi, ie. 'vulnerability:managed' tag
<coreycb> fungi, the problem I'm running into is our distro security team is hesitant to support a package if upstream doesn't provide security support for it
<coreycb> oslo.privsep is the package I'm trying to get security support for
<fungi> coreycb: security "support" is on the individual project developer teams to provide, though if it's tagged as "vulnerability:managed" then our central vulnerability management team provides oversight and imposes a more strict/rigorous process for their disclosure and reporting
<fungi> in the end though, it still winds up being the developers on each project who produce the security fixes and backports
<coreycb> fungi, ok that clears it up, thanks
<fungi> coreycb: the vmt's process is documented at https://security.openstack.org/vmt-process.html and we encourage teams to follow it even for deliverables without vulnerability:managed
<fungi> and we also still consult with teams on issues the vmt isn't overseeing, as time permits
<coreycb> fungi, ok so in the end if a CVE is reported for say, oslo.privsep, you'd expect the oslo.privsep developers to handle that appropriately and consult with the VMT if needed
<fungi> coreycb: correct
<coreycb> fungi, it does seem like there should be an effort for security sensitive projects to be tagged 'vulnerability:managed', like oslo.privsep. but i imagine it's also a resource issue as everything is.
<fungi> though generally a cve wouldn't be reported to the oslo.privsep team so much as a suspected vulnerability would be reported and then they would request a cve assignment for it
<fungi> coreycb: sure, oslo.privsep is relatively new too, so i think its authors simply haven't sought that level of assistance out yet
<fungi> coreycb: and we're still in the last stages of hashing out a threat analysis process for deliverables that want direct vmt overisght. we used to personally review the source of each before taking it on, but as the project has scaled up that's not something a handful of already busy people can tackle so we're trying to collaborate on a way that projects can work together on analyzing themselves and
<fungi> each other
<coreycb> fungi, I completely understand that
<coreycb> fungi, thanks for the discussion
<fungi> the openstack security team (of which the vmt is only a small part) have embarked on a http://git.openstack.org/cgit/openstack/security-analysis/ repo where standardized analyses can be curated
<fungi> which will make it easier for the vmt to be directly involved in reported vulnerabilities for more deliverables in the future

[Corey Bryant (corey.bryant)]

I share the same concern about maturity. Unfortunately this is in the mainline code path for nova and cinder in Newton. The good news is this is small package at ~1100 LOC.

[Corey Bryant (corey.bryant)]

It's worth noting that very few OpenStack projects are tagged with 'vulnerability:managed', and only one of the oslo libraries are. http://governance.openstack.org/reference/tags/vulnerability_managed.html.

[Seth Arnold (seth-arnold)]

James and Corey, thanks for the feedback.

I reviewed python-oslo.privsep version 1.13.0-0ubuntu1 as checked into
yakkety; this shouldn't be considered a full security audit.

oslo.privsep tries to provide more granular tools than calling sudo from
openstack scripts, and implements an RPC mechanism using yaml across
a socket to a more privileged execution environment for finer-grained
access.

I did not discover any CVEs in our database

- Build-Depends: debhelper, dh-python, openstack-pkg-tools
- This package can spawn on-demand daemons needed for the privsep RPC
  mechanism to function; it mostly daemonizes correctly but the umask(0)
  setting feels archaic and prone to fail-open problems.
- pre/post inst/rm scripts clean up after themselves, but a lintian error
  indicates a problem with the update-alternatives tool that ought to be
  fixed
- No initscripts
- No dbus services
- No setuid executables
- python3-privsep-helper and python2-privsep-helper executables in path
- No sudo fragments, but uses sudo internally
- No udev rules
- I didn't inspect the test suite closely; 31 tests are run during the
  build, which feels on the small side, but it's something
- Mostly-clean build logs

- A subprocess is spawned via subprocess.Popen() -- while it passes a
  string, and thus lacks the correctness of an array-based execution, the
  string does appear to be constructed from configuration file contents,
  and is handled with shell=False. It may not be ideal but it's probably
  fine.
- No file IO
- Minimal logging
- Does not itself use environment variables, module imports may
- Uses setuid, setgid, setgroups, prctl to manipulate capabilities
  Uses CFFI and hard-codes capabilities numbers for some caps
- No cryptography
- Uses unix networking sockets
- There are privileged portions of code, reached via a unix domain socket
  from the 'unprivileged' side of the codebase.
- No temporary file handling
- No WebKit
- No javascript
- No policykit

While most of this project was well-developed, I have my concerns about
specific aspects of the system. It is probably still an improvement over
the status quo from before the package's introduction. It doesn't feel
quite ready yet but I understand that removing it would be complicated,
and 16.10 will only be supported for nine months, so if it's a too-large
risk, the consequences are bounded.

We may need the server team's help adapting projects in the event one or
more of the these bugs results in necessary changes to clients:

https://bugs.launchpad.net/bugs/1628348
https://bugs.launchpad.net/bugs/1628360
https://bugs.launchpad.net/oslo.privsep/+bug/1628738

Security team ACK for promoting python-oslo.privsep to main.

Thanks

[Steve Langasek (vorlon)]

Override component to main
python-oslo.privsep 1.13.0-0ubuntu1 in yakkety: universe/misc -> main
python-oslo.privsep 1.13.0-0ubuntu1 in yakkety amd64: universe/python/optional/100% -> main
python-oslo.privsep 1.13.0-0ubuntu1 in yakkety arm64: universe/python/optional/100% -> main
python-oslo.privsep 1.13.0-0ubuntu1 in yakkety armhf: universe/python/optional/100% -> main
python-oslo.privsep 1.13.0-0ubuntu1 in yakkety i386: universe/python/optional/100% -> main
python-oslo.privsep 1.13.0-0ubuntu1 in yakkety powerpc: universe/python/optional/100% -> main
python-oslo.privsep 1.13.0-0ubuntu1 in yakkety ppc64el: universe/python/optional/100% -> main
python-oslo.privsep 1.13.0-0ubuntu1 in yakkety s390x: universe/python/optional/100% -> main
python-oslo.privsep-doc 1.13.0-0ubuntu1 in yakkety amd64: universe/doc/optional/100% -> main
python-oslo.privsep-doc 1.13.0-0ubuntu1 in yakkety arm64: universe/doc/optional/100% -> main
python-oslo.privsep-doc 1.13.0-0ubuntu1 in yakkety armhf: universe/doc/optional/100% -> main
python-oslo.privsep-doc 1.13.0-0ubuntu1 in yakkety i386: universe/doc/optional/100% -> main
python-oslo.privsep-doc 1.13.0-0ubuntu1 in yakkety powerpc: universe/doc/optional/100% -> main
python-oslo.privsep-doc 1.13.0-0ubuntu1 in yakkety ppc64el: universe/doc/optional/100% -> main
python-oslo.privsep-doc 1.13.0-0ubuntu1 in yakkety s390x: universe/doc/optional/100% -> main
python3-oslo.privsep 1.13.0-0ubuntu1 in yakkety amd64: universe/python/optional/100% -> main
python3-oslo.privsep 1.13.0-0ubuntu1 in yakkety arm64: universe/python/optional/100% -> main
python3-oslo.privsep 1.13.0-0ubuntu1 in yakkety armhf: universe/python/optional/100% -> main
python3-oslo.privsep 1.13.0-0ubuntu1 in yakkety i386: universe/python/optional/100% -> main
python3-oslo.privsep 1.13.0-0ubuntu1 in yakkety powerpc: universe/python/optional/100% -> main
python3-oslo.privsep 1.13.0-0ubuntu1 in yakkety ppc64el: universe/python/optional/100% -> main
python3-oslo.privsep 1.13.0-0ubuntu1 in yakkety s390x: universe/python/optional/100% -> main
22 publications overridden.