[buildd-tools-devel] schroot unionfs security model
Tim Abbott
tabbott at ksplice.com
Thu Aug 13 13:06:42 UTC 2009
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
More information about the Buildd-tools-devel
mailing list