[buildd-tools-devel] schroot unionfs security model

[Geoffrey Thomas]

On Mon, 28 Sep 2009, Roger Leigh wrote:

> 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.
>>
>> 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...
>
> The current master branch in git now removes all but the user creating
> the session from users and root-users, and all entries from groups and
> root-groups so only the user and root may access the session.  The user
> is kept in users or root-users depending on if they were in root-users
> or root-groups initially or not.
>
> If you'd like to give this a try and let me know if it's what you were
> looking for, I'd be very grateful.

I finally got a chance to test out this code; it does do what I want, 
namely, that one person listed under "users" can't enter or end the 
session of another person.

The one new edge case I can think of is that root should have the ability 
to enter and end any chroot/session, but that appears to still work.

Thanks,
-- 
Geoffrey Thomas
geofft at mit.edu