[buildd-tools-devel] schroot unionfs security model

[Roger Leigh]

[I posted this a few days back, but it never made the list for some
reason (local MTA problem most likely)]

On Thu, Aug 13, 2009 at 09:06:42AM -0400, Tim Abbott wrote:
> 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.

This analysis is correct.  The access permissions given to the cloned
session are identical to those of the original chroot definition.  This
is a known lacking, which I would like to see fixed.

> 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...

This is the solution I was thinking of, though I haven't implemented
anything yet.  Now that the chroot facet work is mostly done, this
type of session-specific metadata can be added to the session facet,
and can potentially include other data:

- timestamp of cloned session creation
- list of allowed users (defaults to user creating it)
- list of allowed groups (defaults to empty?)
- use count?
- any other per-session statistics and data that we would like

> 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).

I think the problem, which is at its root is a design issue, is that
schroot has always given session access to all users and groups who
are specified in the chroot definition.  Except for the not very widely
used lvm-snapshot support, this hasn't been a pressing issue in the
past, but unionfs support certainly makes this undesirable for some use
cases.  I have been considering what to do for a while, and I think
that your solution is already the way to go here.

I'll probably hold off on making this change until after we have made a
good test release, but we should get it done for the following release.


Regards,
Roger


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.