emerge --version (I doubt you need full --info output) Portage 2.1.1_pre2-r2 (default-linux/amd64/2006.0, gcc-4.1.1/amd64-hardened, glibc-2.4-r3, 2.6.16-hardened-r7 x86_64) After a fresh emerge bind (bind-9.3.2-r1), setting CHROOT in /etc/conf.d/named, and running emerge --config (as documented in bind's ebuild), I end up with: drwx------ 5 named named 4096 Jul 5 11:56 /var/chroot/named This is a bad, bad idea. By user named owning that dir, it will own / in its chroot. User named can then easily move the existing subdirs out of the way and create new ones containing trojaned config files, etc. So, breaking BIND and getting access to user named, is likely just one restart of named away from breaking root (it's actually worse with this chroot setup, than if one were running bind without chroot). Proper ownership/permissions would be something like root:named, mode 750. It looks like there are some other ebuilds that know how to do their own chroot-dir setup; I don't know if they make a similar mistake. I did a quick grep to find other possibly similarly- done packages, and then did an emerge; configure chroot; check ownership: # find /usr/portage -name \*.ebuild | \ xargs egrep -l 'CHROOT.*/etc/conf.d/' | \ cut -d/ -f4,5 | sort -u net-dns/bind # named:named mode 700; bad net-misc/dhcp # root:root mode 755; OK net-misc/ip-sentinel # root:root mode 755; OK [1] net-misc/tor # tor:tor mode 700; bad [2] I didn't look at these ebuilds too closely to see what's different about their chroot-setup code, or at their revision histories to see which may have copied code from which, where the bug was introduced and/or fixed, etc. [1] Added ~amd64 to KEYWORDS to test on this box. [2] Most recent tor ebuild doesn't support chroot; had to install one rev back. Thanks, Hank Leininger <hlein@korelogic.com>
> This is a bad, bad idea. By user named owning that dir, it will own / > in its chroot. User named can then easily move the existing subdirs > out of the way and create new ones containing trojaned config files, > etc. So, breaking BIND and getting access to user named, is likely > just one restart of named away from breaking root (it's actually worse > with this chroot setup, than if one were running bind without chroot). So, if bind is remotely compromised, the user named can inject troyan inside its own chroot, thus compromising bind again ? The question is : is there a way to elevate privileges outside of the chroot ?
and the answer is no :) I dont consider this a security bug, if you compromise the service you can already patch the process to do whatever you want, but you cant break out of the chroot. Nevertheless, I would agree that this is a configuration error, so reassigning to the owners.
fixed net-dns/bind - 9.2.6-r3 and 9.3.2-r3. reassigning to humpback for net-misc/tor.
Fixed tor-0.1.0.18-r1.
