[Bug 1543748] Re: [MIR] designate

Seth Arnold 1543748 at bugs.launchpad.net
Wed Aug 10 02:18:41 UTC 2016


I reviewed designate version 1:3.0.0~b2-0ubuntu1 as checked into Ubuntu
Yakkety. This shouldn't be considered a full security audit but rather a
quick gauge of maintainability.

- Two CVEs in our UCT database, both related to a tenant publishing
  invalid DNS data that caused other DNS services problems. The OpenStack
  security team handled the issue well.

- designate provides an API to backend storage systems for several DNS
  servers so OpenStack tenants can publish DNS data using designate's API.
  It has extremely complicated interfaces:
  - It provides a REST API for clients to use
  - It directly interacts with backend databases for a variety of DNS servers
  - It interacts with DNS servers to trigger AXFR/IXFR transfers and
    verify that updates completed as anticipated
  - It supports both synchronous and asynchronous modes of operation which
    introduce complicated native threading and green threading interfaces
    internally.

- Build-Depends: debhelper, dh-python, dh-systemd, openstack-pkg-tools,
  python-all, python-setuptools, python-sphinx, python-babel, python-coverage,
  python-debtcollector, python-designateclient, python-dnspython,
  python-eventlet, python-fixtures, python-flask, python-greenlet,
  python-hacking, python-jinja2, python-jsonschema, python-keystonemiddleware,
  python-memcache, python-migrate, python-mock, python-netaddr,
  python-neutronclient, python-oslo.concurrency, python-oslo.config,
  python-oslo.context, python-oslo.db, python-oslo.i18n, python-oslo.log,
  python-oslo.messaging, python-oslo.middleware, python-oslo.policy,
  python-oslo.reports, python-oslo.rootwrap, python-oslo.serialization,
  python-oslo.service, python-oslo.utils, python-oslosphinx, python-oslotest,
  python-paste, python-pastedeploy, python-pbr, python-pecan,
  python-pkg-resources, python-requests, python-requests-mock, python-routes,
  python-six, python-sphinxcontrib-httpdomain, python-sqlalchemy,
  python-stevedore, python-suds, python-tempest-lib, python-testscenarios,
  python-testtools, python-tooz, python-webob, python-webtest, python-werkzeug,
  python-keystoneauth1, python-zake, subunit, testrepository,
- Usual oslo_service openstack service startup
- pre/post inst/rm look to be entirely automatically added boilerplates
- init scripts look like usual boilerplate
- No dbus service
- No setuid executables
- A handful of new binaries in the PATH:
  - designate-agent
  - designate-api
  - designate-central
  - designate-manage
  - designate-mdns
  - designate-pool-manager
  - designate-rootwrap
  - designate-sink
  - designate-zone-manager
- Includes sudo configuration:
  Defaults:designate !requiretty
  designate ALL = (root) NOPASSWD: /usr/sbin/rndc
  designate ALL = (root) NOPASSWD: /usr/bin/designate-rootwrap /etc/designate/rootwrap.conf *
  Note that the Ubuntu security teams does not consider rootwrap to be a
  root-hard boundary layer. rndc is also unlikely to be programmed to be
  root-hard. designate should be considered equivalent to root.
- No udev rules
- No cronjobs
- Large test suite run during build

- Processes are spawned, all using array-mechnanisms in real code, test
  code used strings
- Environment variables only explicitly used in test code
- Logging looked reasonable
- One chmod() call in one backend, looked safe
- Does not itself do cryptography
- Network input is managed via usual OpenStack middleware layers
- Extensive SQL use; most uses via sqlalchemy layer, a few direct uses of
  SQL but safe binding-based approaches were used with parameters
- I did not inspect closely enough to see if privileged portions of code
  exist
- Does not use WebKit
- Doesn't explicitly use /tmp outside of tests
- Does not use policykit


Designate is well-programmed but very ambitious and very complicated. It
builds in knowledge of several DNS servers' back-end databases as part of
its operation but I never saw mechanisms to ensure that the database
schema hasn't changed since the backend was authored. This runs the risk
that specific servers may stop working when the servers are upgraded. It
also likely forces some "lowest common denominator" aspects to the API.
(For example, I didn't see any support for DNSSEC.)

DNS is complicated enough on its own that adding a middleware layer may be
fighting against users who may rather just supply zone files or issue API
calls directly to the DNS server.

When I reported a concern, the team responded promptly.

So, I have my doubts about the overall utility of designate but see no
reason why we shouldn't support it.

Security team ACK for promoting designate to main.

Thanks


** Changed in: designate (Ubuntu)
     Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to designate in Ubuntu.
https://bugs.launchpad.net/bugs/1543748

Title:
  [MIR] designate

Status in designate package in Ubuntu:
  New

Bug description:
  [Availability]
  Currently in universe

  [Rationale]
  OpenStack Mitaka requires the designate package. 

  [Security]
  No security history

  [Quality Assurance]
  No prompting during install, all unit tests ran successfully. All current bugs are triaged or in progress.

  [Dependencies]
  All in main.

  [Standards Compliance]
  FHS and Debian Policy compliant.

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

  [Background]
  Designate provides DNS as a service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/designate/+bug/1543748/+subscriptions



More information about the Ubuntu-openstack-bugs mailing list