[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