[buildd-tools-devel] schroot unionfs security model

[Tim Abbott]

Geoffrey Thomas mentioned to me the following interesting potential 
problem in schroot's security model in relation to union mounts:

Suppose that you have a shared access server where you want users to be 
able to access a Debian chroot, and you further want to give them limited 
ability to change the filesystem inside their session chroot (e.g. imagine 
you have a secure setuid program that lets you install new libdevel 
packages for building software, and that's it), without changing the state 
for other users.  You set up the chroot using the new unionfs chroot 
functionality, and make it so any user can create their own a new unionfs 
session chroot.

However, any user who can begin a new such session can also enter other 
users' sessions and change files in the snapshot, and end other users' 
sessions as well.  So our shared access server setup doesn't have the 
security properties that I think one would a priori expect it to have.

The obvious fix is to store which user created a session in 
/var/lib/schroot/session and only give that user and root the ability to 
access their sessions.  I haven't had time to think about whether that 
model causes any problems, or whether e.g. people who can enter the 
source chroot as root should also have access...

Anyway, I thought I'd email you guys now since I am out of time and I 
think this issue is essentially introduced by the unionfs support (which 
makes this "anyone can make their own snapshot" model practical).

	-Tim Abbott