nova_sudoers is brittle, often out of date, and too permissive

Do you mean euca_rootwrap as implemented like this: http://www.sfr-fresh.com/linux/misc/eucalyptus-2.0.2-src-online.tar.gz:a/eucalyptus-2.0.2/util/euca_rootwrap.c?

Unless I'm missing something, this will execute any command with full root privileges, which completely defeats the point of privilege separation. Using sudo is pretty horrible, but at least it can enforce that only a few named commands may be run. Using euca_rootwrap would be hardly any more secure than just running the nova daemons as root.

No, that was the original implementation from Eucalyptus, but this was reworked in Ubuntu in the following patch:
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/eucalyptus/natty/view/head:/debian/patches/18-priv_security.patch

See how that version uses wrappers.conf.
(The patch still hasn't made it upstream Eucalyptus, but that's another story)

In addition to previously written I found a problem with nova_sudoers:

I was trying to delete volumes and I always got an error and volumes change to error_deleting staus. Looking at nova-volume log I found the error happened while trying to run:

sudo dd if=/dev/zero of=/dev/mapper/nova--volumes-volume--00000005 count=1024 bs=1M

Getting:

no tty present and no askpass program specified

I solved this adding:

/bin/dd, \

to nova_sudoers, but this should be included by default.

There are, in fact, three issues.

1/ The current sudoers file is way too permissive. It gives access to so many unrestricted commands that the nova user is as powerful as the root user.

2/ The sudoers setup is a bit brittle because it assumes things about your /etc/sudoers ("must include /etc/sudoers.d").

3/ Whenever a code change in nova introduces the need for a new "sudo" command, the packages fail to introduce in parallel the needed change in the sudoers file, mainly because those are two separate code bases with two separate sets of developers working on it.

Options include:
* Strengthening the nova_sudoers file (precisely limiting options for every command) would address (1)
* Shipping the nova_sudoers in Nova code, or generating it automatically at package-build time, would address (3)
* Writing a specific command wrapper in Nova would address (1) and (3), but suffers of a bit NIH

Not sure what's the best way to care about (2), or if we should just assume a sane sudoers.d support.

Another layer would be to ship apparmor profiles in Ubuntu packaging, though we would encounter issue (3) again.

Separating nova_sudoers into node-specific files sounds like a good idea too (nova user is more exposed on API nodes, and API nodes actually do not need a nova user that has the power of screwing up your network configuration)

as part of nova-rootwrap blueprint

This bug was fixed in the package nova - 2012.1~e3~20120113.12049-0ubuntu1

---------------
nova (2012.1~e3~20120113.12049-0ubuntu1) precise; urgency=low

  [Chuck Short]
  * New upstream version.
  * debian/nova_sudoers, debian/nova-common.install,
    Switch out to nova-rootwrap. (LP: #681774)
  * Add "get-origsource-git" which allows developers to
    generate a tarball from github, by doing:
    fakeroot debian/rules get-orig-source-git
  * debian/debian/nova-objectstore.logrotate: Dont determine
    if we are running Debian or Ubuntu. (LP: #91379)

  [Adam Gandleman]
  * Removed python-nova.postinst, let dh_python2 generate instead since
    python-support is not a dependency. (LP: #907543)
 -- Chuck Short <email address hidden> Fri, 13 Jan 2012 09:51:10 +0100