Hi, util-vserver-0.30.210-r13 comes with a patch adding 3 lines to /usr/lib/util-vserver/defaults/fstab: # shared portage tree #/usr/portage /usr/portage none bind,ro 0 0 #/usr/portage/distfiles /usr/portage/distfiles none bind,rw 0 0 /usr/lib/util-vserver/defaults/fstab is installed as /etc/vservers/foo/fstab per default which handles additional mount points for the vServer foo. Removing the '#' from the 2. line mounts /usr/portage of the host system to /usr/portage of the vServer. Since there is a "ro" in this line you might think this is done in a way an attacker inside the vServer can't poke with it's own /usr/portage and the hosts /usr/portage. But you're wrong. Mounting via --bind ignores all (?) options and mounts /usr/portage of the host system to the vServer being able to alter the hosts portage tree out of a running vServer (unless /usr/portage is on a readonly mounted partition on the host system). Sysadmins using this suggested way to save disk space may end up with a compromised system after emerging packages on the host system. Even other vServers may be compromised this way when more than one vServer got /usr/portage from the host system. Suggested solution: removing the patch
Reassigning to security. Note to reporter: non security devs are not able to access the bug when you restrict it to the security group.
Tavis could you have a look?
Not really a security bug, but if the examples are insecure maybe we should add some warnings or improve the examples. vserver-devs, what do you guys think?
(In reply to comment #0) > Hi, > > util-vserver-0.30.210-r13 comes with a patch adding 3 lines to > /usr/lib/util-vserver/defaults/fstab: > > # shared portage tree > #/usr/portage /usr/portage none bind,ro 0 0 > #/usr/portage/distfiles /usr/portage/distfiles none bind,rw 0 0 > > /usr/lib/util-vserver/defaults/fstab is installed as /etc/vservers/foo/fstab > per default which handles additional mount points for the vServer foo. > > Removing the '#' from the 2. line mounts /usr/portage of the host system to > /usr/portage of the vServer. Since there is a "ro" in this line you might think > this is done in a way an attacker inside the vServer can't poke with it's own > /usr/portage and the hosts /usr/portage. > > But you're wrong. Mounting via --bind ignores all (?) options and mounts > /usr/portage of the host system to the vServer being able to alter the hosts > portage tree out of a running vServer (unless /usr/portage is on a readonly > mounted partition on the host system). That isn't particularly right. The behaviour Marcel described is true for vanilla kernel (even Gentoo/hardened) but vserver-sources (the stable one - 2.0.1-r5, and current testing - >=2.0.2) includes a patch introducing read-only bind-mounts (just like its being discussed for 2.6.19 (?) on the lkml. Anyway you'll need vserver-sources (thus a vserver patched kernel to even _use_ util-vserver), which comes with read-only mount-binds, thus allowing you to bind-mount stuff with '-o bind,ro' (and thus making the mounts _read-only_ for sure). This was introduced as a seperate patch to Linux vServer 2.0.1 (present in the current stable 2.0.1-r5) and is now bundled with 2.0.2.
Closing as FIXED as per Christian's explanation. Thanks!
