[buildd-tools-devel] Bug#526788: Bug#526788: schroot allows a user to do a local DoS

Aurelien Jarno aurel32 at debian.org
Sun May 3 16:03:12 UTC 2009


On Sun, May 03, 2009 at 04:39:23PM +0100, Roger Leigh wrote:
> On Sun, May 03, 2009 at 05:12:01PM +0200, Aurelien Jarno wrote:
> > Package: schroot
> > Version: 1.2.2-1
> > Severity: important
> > Tags: security patch
> > 
> > In script mode, schroot mounts a new tmpfs (with a default size of half
> > the RAM) to act as /dev/shm inside the chroot and for each created
> > chroot (a user can create more than one), as shown below. Those
> > directories are world writable, meaning that a user can fill them, and
> > with them RAM and swap. As soon as the whole RAM and swap have been
> > filled, the kernel starts OOM killing every task, leading to a crash
> > of the machine.
> 
> This is also the case for /lib/init/rw.  There should really be a strict
> size limit placed on it (even on the host).  #390184 BTW.

/lib/init/rw is not world writable, so a normal user can't do anything
here.

> > The correct solution here is to bind mount /dev/shm, as it is already
> > done for /home, /tmp and /dev/pts. The patch below does that:
> 
> We share /home, /tmp for user convenience.  We share /dev/pts because
> there's no choice (we could mount it twice but it's pointless).
> For /dev/shm we are sharing the POSIX SHM and SEM data between host
> and chroot.  My question here is, do we want to share that data?
> 
> I'm perfectly happy with the patch, I just want to question whether
> sharing shared memory is needed or desirable.
> 

I am not sure it is something needed or desirable, however I don't think
it is something that hurts. chroot() is something that only isolates the
filesystem, and a lot of things are already shared between the host and
the chroot.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien at aurel32.net                 http://www.aurel32.net





More information about the Buildd-tools-devel mailing list