BSD jail

BSD jail

[Joshua Hudson]

I had been wanting this functionality myself, but for some reason it never found
its way into the stock kernel.  I looked around, started coding,
looked some more,
coded some more, looked some more until I found this:

http://kerneltrap.org/node/3823

I suppose the reason it wasn't applied is lack of good IPv6 support.

It is perhaps about what I was looking for, but a slightly different method.
My idea was to cause no disturbance to the normal security chain, and
so maintain jails in the following manner (remember, the sys_jail call
is trusted)
 1. Add an additional check to path_lookup (actually, a functioned
called by path_lookup)
to check for jail roots in addition to normal chroots.
 2. Lockdown process visibility to only processes in the same jail.
 3. Lockdown kill/ptrace/setpriority to processes in the same jail.
 4. Lockdown capabilities to a restricted set that prevents novel
means of breaking the jail.
 5. Restrict binding to one IPv4 and one IPv6 address (squash bind to
all to bind to that).
All of this is done in front of the normal security mechansim, so that
some non-default
security module will not accidentally break this.

I provided compatability for exactly the BSD jail(2) call, but did it
without breaking
programs that depend on chroot escapes working (there are a few).

I am currently about a third of the way to completion. This means that
I will finish
unless some other mechanism is provided before I do. I personally
don't care if my
patch is used (if released), but I want this functionality.

Re: BSD jail

[Serge E. Hallyn]

Quoting Joshua Hudson (joshudson@gmail.com):
> I had been wanting this functionality myself, but for some reason it never found
> its way into the stock kernel.  I looked around, started coding,
> looked some more,
> coded some more, looked some more until I found this:
> 
> http://kerneltrap.org/node/3823
> 
> I suppose the reason it wasn't applied is lack of good IPv6 support.

The latest version (which is still quite old) is at
http://www.sf.net/projects/linuxjail and does have ipv6 support.  The last
time I submitted it, Christoph had objected to the way the networking was
done in general.  I've tried twice to float a generalized "per-process
network namespaces" patch, but haven't really found a good approach.

I suspect that the best approach would be to take the linux-vserver
ngnet implementation and convert it to a standalone network namespace
plus virtual network device implementation.  Do you care to give this
a try?

thanks,
-serge

Re: BSD jail

[Joshua Hudson]

On 8/13/05, Serge E. Hallyn <serue@us.ibm.com> wrote:
> The latest version (which is still quite old) is at
> http://www.sf.net/projects/linuxjail and does have ipv6 support.  The last
> time I submitted it, Christoph had objected to the way the networking was
> done in general.  I've tried twice to float a generalized "per-process
> network namespaces" patch, but haven't really found a good approach.
> 
> I suspect that the best approach would be to take the linux-vserver
> ngnet implementation and convert it to a standalone network namespace
> plus virtual network device implementation.  Do you care to give this
> a try?
> 
> thanks,
> -serge

Why would you want a virtual network device implementation? The whole
point of jail()
is a replacement for chroot() for housing untrusted root processes in
a lightweight
manner as reasonable.  I think in one way at least, I have restricted the manner
of jail behavior better than the current linuxjail, by turning off
capabilities rather than
blocking mknod(), mount(), etc.

I do like the idea of patching in through LSM, however not everything
can be done there.
In particular, I could escape from the jail as implemented there by a
classic chroot()
trick.

Re: BSD jail

[Serge E. Hallyn]

Quoting Joshua Hudson (joshudson@gmail.com):
> Why would you want a virtual network device implementation? The whole

So that a jailed process can use the net but can't use your network
address (intercept ssh, imap/stunnel, etc).

> I do like the idea of patching in through LSM, however not everything
> can be done there.
> In particular, I could escape from the jail as implemented there by a
> classic chroot()
> trick.

As Alan Cox had noted,  you can escape with the help of an outside
process, but the classic chroot(TEMPDIR);chdir(..);...;chroot(.)
did not work against either the namespace-based or certainly not the
older (inode_permission-based) implementation.

But in the end vserver with read-only bind mounts seems a better way to
go imo.

-serge

Re: BSD jail

[Joshua Hudson]

All right, I'll see what I can come up with. This is quite a tall order.
1. A mechanism for creating virtual network interfaces
2. A mechanism for restricting binding to certain network interfaces
3. A mechanism for binding certain network interfaces.
4. The jail code itself

Much of the work is already done in other projects, but it requires grafting.
It seems much simpler to bind the jail's address to an network alias
(such as eth0:1),
and bind the jail to the address of the alias.

Re: BSD jail

[Joshua Hudson]

Quoting Serge E. Hallyn (serue@us.ibm.com)
>Quoting Joshua Hudson (joshudson@gmail.com):
> Why would you want a virtual network device implementation? The whole
>
>So that a jailed process can use the net but can't use your network
>address (intercept ssh, imap/stunnel, etc).

[snip]

>But in the end vserver with read-only bind mounts seems a better way to
>go imo.
Latest version of linux vserver source: 100K bzipped
Latest version of linux-jail: 34K uncompressed

To build a virtual network device requires code for the device, code
for routing the device
in the kernel, some way to tell the router that this machine is hosted
through the host
machine's ethernet card, and control of which processes use which
network devices.

Way too much work for something intended to be simple and have essentially no
overhead.  All this work only gets jailed processes the ability to use
127.0.0.1.
The rest I can already do with eth0:1 and the specs for jail(2) from BSD.

Re: BSD jail

[Joshua Hudson]

> 
> To build a virtual network device requires code for the device, code
> for routing the device
> in the kernel, some way to tell the router that this machine is hosted
> through the host
> machine's ethernet card, and control of which processes use which
> network devices.
> 
I've bombed out. I don't understand how the network devices work well
enough to do any of this.