[MIR] neutron-vpnaas

[Corey Bryant]

[Availability]
Currently in universe

[Rationale]
Extension for OpenStack Neutron that provides VPNaaS.
Note: neutron-vpnaas was promoted to main in the past and then later demoted. I believe it was demoted due to [1], however development has since picked up and we'd like to get it back into main.

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107384.html

[Security]
No security history

[Quality Assurance]
Package works out of the box with no prompting. There are no major bugs in Ubuntu and there are no major bugs in Debian. Unit tests are run during build.

[Dependencies]
All are in main

[Standards Compliance]
FHS and Debian Policy compliant.

[Maintenance]
Python package that the Ubuntu Server Team will take care of.

[Background]
VPNaaS (VPN-as-a-Service) is a Neutron extension that introduces VPN feature set.
https://wiki.openstack.org/wiki/Neutron/VPNaaS

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1482765/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Michael Terry (mterry)]

This is OK from a packaging side (nice unit tests!).

It has a system daemon, so I'll subscribe the security team for a look see.

It also has been removed from Debian testing, but that's no big deal, it was a temporary thing to let a transition go through.

More troublingly, we have never sync'ed up with Debian. And notably, are now using a separate versioning scheme. Are we truly doomed to never be able to merge from Debian as is? I guess we'd have to get them to bump their version to 2: or 3: in order to make that work. Still, we should try to merge everything but the version if possible, will make merges simpler. Any comment on this mess?

[Corey Bryant (corey.bryant)]

The core OpenStack packages (https://code.launchpad.net/~ubuntu-server-dev/+git) are not in sync with Debian as we tend to lead the way in Ubuntu on them. For example, neutron-lbaas in Debian is still at kilo 2015.1.1 in sid whereas wily is on beta 2 of liberty 7.0.0.

[Corey Bryant (corey.bryant)]

There are other reasons as well, such as the debian packages using debconf. There was an attempt to converge the core packages earlier this year but we ended up deciding not to. We have worked on converging many packages though in this cycle. For example the python OpenStack clients are mostly all converged and synced from Debian at this point.

[Michael Terry (mterry)]

Understood, OK

[Jamie Strandboge (jdstrand)]

FYI, it's possible this may not be done for 15.10 based on other outstanding higher priority MIRs (juju, golang, fwupdate, lxd, angular.js (MAAS))

[Jamie Strandboge (jdstrand)]

This will not be reviewed in time for 15.10.

[Jamie Strandboge (jdstrand)]

Is this still needed for 16.04?

[Corey Bryant (corey.bryant)]

James, Yes please.

[Corey Bryant (corey.bryant)]

sorry, Jamie

[Seth Arnold (seth-arnold)]

I reviewed neutron-vpnaas version 2:8.0.0~rc1-0ubuntu1 as checked into
xenial. This shouldn't be considered a full security audit but rather a
quick gauge of maintainability.

I had to enable universe for this build:

 builddeps:neutron-vpnaas : Depends: dh-systemd but it is not installable
                            Depends: python-hacking but it is not going to be installed

- neutron-vpnaas knows how to configure network namespaces and several
  ipsec daemons to provide VPNs as a servive to openstack
- Build-Depends: debhelper, dh-python, dh-systemd, openstack-pkg-tools,
  python-all, python-pbr, python-setuptools, python-sphinx
- Build-Depends-Indep: alembic, python-coverage, python-fixtures,
  python-hacking, python-jinja2, python-mock, python-netaddr,
  python-neutron, python-neutron-lib, python-oslo.concurrency,
  python-oslo.config, python-oslo.db, python-oslo.log,
  python-oslo.messaging, python-oslo.serialization, python-oslo.service,
  python-oslo.utils, python-oslosphinx, python-oslotest, python-requests,
  python-requests-mock, python-six, python-sqlalchemy,
  python-testresources, python-testscenarios, python-testtools,
  python-webob, python-webtest, subunit, testrepository,

- neutron-vpn-agent starts via initscripts, though I lose the flow of
  execution nearly immediately -- no idea if it daemonizes correctly, but
  there's no fork() or setsid() calls in the codebase
- pre/post inst/rm scripts automatically generated
- No dbus services
- No setuid
- /usr/bin/neutron-vpn-netns-wrapper and /usr/bin/neutron-vpn-agent
  binaries
- No sudo fragments
- No udev rules
- Decent-sized tests run during build but I assume they're mostly mocked
- No cron jobs

- Dependency injection makes it difficult to trace filesystem writes
- Some adapter classes know how to configure:
  - cisco csr client
  - cisco ipsec
  - fedora strongswan
  - ipsec
  - libreswan ipsec
  - strongswan ipsec
  - vyatta ipsec

- Only environment variable referenced was HUDSON_PUBLISH_DOCS in doc/
- There is a racy chmod() call in vpn_utils.py that is likely exploitable
  if the machine in question has untrusted users
- Extensive configuration of cryptography but none implemented here
- I did not investigate the ipsec configurations for sanity or safety; I
  did see that many were configured to use sha1 authentication. sha1 is
  being phased out nearly everywhere but its use as online integrity
  checks for tcp/ip streams may still be acceptable.
- Outgoing networking initiated via paramiko, may be more
- temp file handling looks poor, /tmp is used with what looks to be
  often-predictable names, sometimes files aren't cleaned up
- No webkit
- No policykit

- We will consider rootwrap is an _advisory_ service only, much like php's
  safe_open. Any issues with rootwrap will probably be treated as "low" or
  lower in our workflow.
- write_key_to_compute_node() doesn't check write_key_to_local_path()
  error return
- write_key_to_compute_node() doesn't clean up local_path
- write_key_to_local_path() race condition, creates local_key_file and then
  sets permissions on the file -- an attacker could open the file for
  reading between the two system calls and then read ...

[Michael Terry (mterry)]

OK, with Seth's comments and my previous review, this looks good.

[Steve Langasek (vorlon)]

Override component to main
neutron-vpnaas 2:8.0.0-0ubuntu2 in xenial: universe/python -> main
neutron-vpn-agent 2:8.0.0-0ubuntu2 in xenial amd64: universe/net/optional/100% -> main
neutron-vpn-agent 2:8.0.0-0ubuntu2 in xenial arm64: universe/net/optional/100% -> main
neutron-vpn-agent 2:8.0.0-0ubuntu2 in xenial armhf: universe/net/optional/100% -> main
neutron-vpn-agent 2:8.0.0-0ubuntu2 in xenial i386: universe/net/optional/100% -> main
neutron-vpn-agent 2:8.0.0-0ubuntu2 in xenial powerpc: universe/net/optional/100% -> main
neutron-vpn-agent 2:8.0.0-0ubuntu2 in xenial ppc64el: universe/net/optional/100% -> main
neutron-vpn-agent 2:8.0.0-0ubuntu2 in xenial s390x: universe/net/optional/100% -> main
python-neutron-vpnaas 2:8.0.0-0ubuntu2 in xenial amd64: universe/python/optional/100% -> main
python-neutron-vpnaas 2:8.0.0-0ubuntu2 in xenial arm64: universe/python/optional/100% -> main
python-neutron-vpnaas 2:8.0.0-0ubuntu2 in xenial armhf: universe/python/optional/100% -> main
python-neutron-vpnaas 2:8.0.0-0ubuntu2 in xenial i386: universe/python/optional/100% -> main
python-neutron-vpnaas 2:8.0.0-0ubuntu2 in xenial powerpc: universe/python/optional/100% -> main
python-neutron-vpnaas 2:8.0.0-0ubuntu2 in xenial ppc64el: universe/python/optional/100% -> main
python-neutron-vpnaas 2:8.0.0-0ubuntu2 in xenial s390x: universe/python/optional/100% -> main
Override [y|N]? y
15 publications overridden.

[Corey Bryant (corey.bryant)]

I've moved this back to New since it was moved to universe in Bionic and we'd like to get it back into main. I've updated the [Rationale] section with reasoning. Thanks!

[Mathieu Trudel-Lapierre (cyphermox)]

This already has been reviewed and was in main in artful; if you need it back in main (and to stay there), you will also need to have something Depends on it, or have it listed in a seed.

Setting back to Fix Committed -- no further review necessary.

[Corey Bryant (corey.bryant)]

Hi Mathieu, I've added python-neutron-vpnaas to supported-misc-servers to seed it. Is there any possibility to also get this seeded in bionic?

[Matthias Klose (doko)]

assigning to the security team, needing an ack that the version in 18.04 can be supported. Note that the package already is in main in 16.04.

[Seth Arnold (seth-arnold)]

I reviewed neutron-vpnaas version 2:13.0.0-0ubuntu1 as checked into
cosmic. This shouldn't be considered a full security audit. I especially
did not audit the VPN configurations that it provides.

- No CVEs in our database
- neutron-vpnaas provides an interface for OpenStack administrators to
  create VPNs using a variety of VPN tools
- *huge* list of build-depends. I'm not going to paste them all in here,
  it's really very surprising. There's 83 packages.
- Does not itself do networking
- Does not daemonize
- pre/post inst/rm scripts autogenerated
- No initscripts
- No systemd units
- No DBus services
- No setuid files
- python3-neutron-vpn-netns-wrapper and python2-neutron-vpn-netns-wrapper
  executables in /usr/bin
- No sudoers fragments
- No udev rules
- Extensive testsuite, unknown utility
- No cronjobs

- Subprocesses extensively spawned
- File operations are normally to well-known locations
- No environment use
- Privileged operations looked racy
- Networking done mostly via spawning ssh
- All /tmp uses look to be in test or CI
- No use of WebKit
- No use of JavaScript
- No use of Policykit

neutron-vpnaas was previously in main. I don't recall it being a
maintenance burden in the past, so this audit is fairly truncated compared
to if this were a new package entirely.

It still drastically uses string-based command executions via ssh.

Whoever can use this interface should be considered to have full control
over the entire OpenStack environment. Upstream OpenStack security team
wasn't too worried about anything I reported last time around, so this is
probably also their threat model.

write_key_to_local_path() has a race condition in writing a key. Probably
OpenStack networking and compute nodes only ever have completely trusted
users interacting with the systems.

Security team ACK for promoting neutron-vpnaas to main with the provision
that the server team promises to help provide quality assurance in the
event updates are needed. We're not in a position to test all the VPNs
that this can configure.

Thanks

[Seth Arnold (seth-arnold)]

Oh yes, promoting neutron-vpnaas for main for 18.04 LTS is also fine by us.

Thanks

[Dimitri John Ledkov (xnox)]

and it got dropped from seeds again, because python2 package was seeded instead of python3. seeding python3 package back in.

[Matthias Klose (doko)]

promoted again