[buildd-tools-devel] Bug#637870: Provide more isolation than just chroot

[Roger Leigh]

On Mon, Aug 15, 2011 at 12:46:31PM +0200, Vincent Bernat wrote:
> Recent Linux kernels allow more advanced isolation than just
> chrooting. From clone(2) manpage, those possibilities exist:
> 
>  - CLONE_NEWPID: new PID namespace, including the fact that when the
>    initial process dies (in case of schroot, this could be the shell),
>    all other processes start die as well. This would be a very cool
>    feature when starting daemons in the chroot.
>  - CLONE_NEWNS: mentioned in bug #488225.
>  - CLONE_NEWIPC: new IPC namespace, with complete destruction on exit
>  - CLONE_NEWNET: new network namespace, maybe could be done later
>    since it needs to be configured properly to be useful.
>  - CLONE_NEWUTS: not sure when it is useful
> 
> CLONE_NEWPID + CLONE_NEWNS + CLONE_NEWIPC would be great!
> 
> I am unsure if this can be done into setup scripts but I will look at
> it. Maybe with an helper?

On the master branch (1.7.0 development), I've now implemented
initial unshare(2) support.  Currently limited to CLONE_NEWNET,
but others can be added easily now the groundwork is done.

At the moment, as discussed in this report already, the way schroot
handles sessions makes is impractical to support NEWPID and NEWNS.
But I plan longer-term to make this possible, but this requires
fairly significant refactoring.  We'd need to make a schroot
session a persistent process you connect to, probably over a
local socket, so that the pid and filesystem namespaces can
persist.  This would actually be beneficial for a number of other
reasons, but it's going to be a lot of work, so won't be done
immediately.

Others that can be implemented immediately:
NEWIPC
CLONE_SYSVSEM
CLONE_NEWUTS

Because these all take effect at exec time, they would isolate
each command started in the chroot, rather than the chroot as
a whole--that will have to wait until we have socket-based
persistence.  But still useful for e.g. buildds since they
prevent leaking of resources and complete networking
restriction just for the build step.


With the current implementation, I've make it work with the
  -o unshare.newnet=true
user option on the command-line.  You can also set it when
creating a session, and it should affect all commands run
in that session.

I'm not sure if this is the best possible interface though--
do we want to tie the options directly to the linux unshare()
interface?  I'm not sure yet.  Depends on how linux-specific
this facility is to be.  Currently linux-only.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800