euca_rootwrap makes eucalyptus user equivalent to root

This report is currently private. I don't know that we have the resources to solve this problem in time for Karmic. This bug is being opened against Ubuntu and upstream to track it, however, as this is something we absolutely must fix in Lucid.

:-Dustin

Euca uses root privs for a specific sub-set of actions (see attached). I think as a first-pass, we need to:

1) use capabilities, not "uid 0"
2) add logic to the wrapper to only allow specific commands/paths, and adjust capabilities as appropriate
3) use fully qualified paths to commands

continued...

4) stop using system() on a string and start using fork/exec against an array of arguments. (see attached list of system() uses)

5) multiple uses of unsafe /tmp files (see attached)

For 1,2,3: the general categories seem to be:
 a) libvirt (can't these operations be done with euca in the libvirt group?)
 b) vlan, bridge, ip configurations: CAP_NET_ADMIN + CAP_NET_RAW should be sufficient for these commands.
 c) LVM: CAP_SYS_ADMIN should be sufficient.
 d) dd: why does this need root privs?

Is the AOE manager used?
 e) process management: should use some kind of sanity-wrapper with CAP_KILL (is this really needed? kill -9 is pretty harsh)
 f) module loading: should be done via packaging not via call-outs to modprobe (also note CAP_SYS_MODULE)

Having the wrapper select caps based on the path of the command seems like a starting point. Getting rid of needless wrapper calls would be nice too: "which", "cat", "dd"...

/sbin/ip
/usr/bin/powerwake
/sbin/iptables
/sbin/iptables-save
/sbin/iptables-restore
/usr/share/eucalyptus/euca_ipt
/bin/chgrp
/bin/chmod
/usr/sbin/dhcpd3
/usr/sbin/vtund
/sbin/vconfig
/usr/sbin/brctl
/usr/bin/virsh
/etc/init.d/powernap
/usr/share/eucalyptus/get_sys_info
/usr/share/eucalyptus/get_xen_info
/usr/sbin/vblade
/sbin/lvm
/sbin/dmsetup
/usr/share/eucalyptus/add_key.pl
/usr/share/eucalyptus/partition2disk
/bin/kill
/usr/share/eucalyptus/gen_kvm_libvirt_xml
/usr/share/eucalyptus/gen_libvirt_xml
/usr/share/eucalyptus/detach.pl
/sbin/modprobe
/sbin/losetup
/sbin/pvcreate
/sbin/vgcreate
/sbin/vgextend
/sbin/lvremove
/sbin/lvchange
/sbin/vgremove
/sbin/pvremove
/sbin/vgreduce
/sbin/dmsetup
/bin/cat
/bin/dd

> /usr/bin/powerwake

Powerwake should not require root privileges, except perhaps for
updating /var/cache/powerwake/ethers with cached mac addresses. I
don't *think* Eucalyptus is using this feature, but if it is, this
could simply be solved by adjusting the privileges on that file.

:-Dustin

Well, much to my chagrin, capabilities changed in 2.6 so that they do not
survive exec(), which weakens my design a bit, but at least I've got it
working with a limited configuration file. The chmod/chgrp thing still
needs a wrapper, but as I don't have a test environment, I'm not sure what
the wrapper for that should be checking as a valid path.

Beyond that, I'm pretty happy -- it reduces a "eucalyptus" group access
attack to mostly a DoS (destroying disks, network, etc). I tried to
limit the use of "dd", but it seems like there isn't currently a way
to avoid reading/writing LV contents (due to the snapshot behavior).
Tightening that would be nice. (i.e. only read/write managed LVs.)

This bug was fixed in the package eucalyptus - 1.6~bzr931-0ubuntu2

---------------
eucalyptus (1.6~bzr931-0ubuntu2) karmic; urgency=low

  [ Kees Cook, Dan Nurmi, Dustin Kirkland ]
  * debian/control, util/Makefile, util/chgrp-dhcpd, util/chmod-dhcpd,
    util/dd-lv, util/euca_rootwrap.c, util/modprobe-aoe,
    util/wrappers.conf: LP: #436977
    - rework euca_rootwrap to be a bit more secure;
    - whitelist the commands that eucalyptus needs to run as root in a
      configuration file
    - build-depend on libcap-dev
  * debian/eucalyptus-common.install: ensure the new utilities and conf
    file gets installed
  * debian/patches/03-DESTDIR.patch: updated for new util/Makefile
    utility installs

 -- Dustin Kirkland <email address hidden> Wed, 14 Oct 2009 18:12:51 -0500

This issue is now being tracked upstream at http://eucalyptus.atlassian.net/browse/EUCA-2662

Please watch that issue for further updates.