euca_rootwrap makes eucalyptus user equivalent to root

Bug #436977 reported by Dustin Kirkland  on 2009-09-26
268
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Eucalyptus
Confirmed
Undecided
Daniel Nurmi
eucalyptus (Ubuntu)
High
Dustin Kirkland 
Karmic
High
Dustin Kirkland 

Bug Description

ubuntu@euca-cc3:~$ ls -alF /usr/lib/eucalyptus/euca_rootwrap
-rwsr-xr-- 1 root eucalyptus 6160 2009-09-25 15:27 /usr/lib/eucalyptus/euca_rootwrap*

This program allows the eucalyptus user to run basically anything as root.

We acknowledge that the eucalyptus user periodically needs to do privileged operations. This needs to be handled in a more fine-grained manner, though.

:-Dustin

Dustin Kirkland  (kirkland) wrote :

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

Changed in eucalyptus:
status: New → Confirmed
Changed in eucalyptus (Ubuntu):
status: New → Confirmed
importance: Undecided → High
Kees Cook (kees) wrote :

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...

Kees Cook (kees) wrote :

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

Kees Cook (kees) wrote :

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

Kees Cook (kees) wrote :

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"...

Kees Cook (kees) on 2009-09-29
Changed in eucalyptus (Ubuntu Karmic):
milestone: none → ubuntu-9.10
Daniel Nurmi (nurmi) wrote :

/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

Changed in eucalyptus (Ubuntu Karmic):
status: Confirmed → Triaged
Kees Cook (kees) wrote :

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.)

Kees Cook (kees) on 2009-10-13
visibility: private → public
Thierry Carrez (ttx) on 2009-10-14
tags: added: eucalyptus
Thierry Carrez (ttx) on 2009-10-14
Changed in eucalyptus (Ubuntu Karmic):
assignee: nobody → Dustin Kirkland (kirkland)
Changed in eucalyptus (Ubuntu Karmic):
status: Triaged → In Progress
Launchpad Janitor (janitor) wrote :

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

Changed in eucalyptus (Ubuntu Karmic):
status: In Progress → Fix Released
Changed in eucalyptus:
assignee: nobody → Daniel Nurmi (nurmi)
Andy Grimm (agrimm) wrote :

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

Please watch that issue for further updates.

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers