login
Search
Serge Hallyn posted a set of three patches to the lkml that together implement a subset of the BSD Jail functionality [story] into the Linux kernel using the Linux Security Modules (LSM) framework. Serge explains that with the patch, "a process in a jail lives under a chroot which is not vulnerable to the well-known chdir(...)(etc)chroot(.) attack against normal chroots, and may be locked to one ip address."
The third patch in the set contains documentation for the module, which notes that in addition to the features listed above, if a process is in a jail it cannot mount or unmount, it cannot send signals outside of the jail, it cannot ptrace processes outside of the jail, it cannot create devices, it cannot renice processes, it cannot load or unload kernel modules, it cannot change network settings, and it cannot see the contents of /proc/<pid> entries of processes not within the same jail. Following feedback from Alan Cox [interview], Serge provided an updated patch that adds preliminary support for IPv6 within the jail.
From: Serge Hallyn [email blocked] To: Chris Wright [email blocked], linux-kernel@vger.kernel.org Subject: [PATCH] BSD Jail LSM (1/3) Date: Fri, 10 Sep 2004 15:21:45 -0500 Attached is a patch which introduces a new LSM hook, security_task_lookup. This hook allows an LSM to mediate visibility of /proc/<pid> on a per-process level. It applies cleanly to 2.6.8.1 and has been tested on xSeries, pSeries, and zSeries. The bsdjail lsm which will be sent next is a user of this hook. Please apply. Signed-off-by: Serge E. Hallyn [email blocked] -serge [patch]
From: Serge Hallyn [email blocked] Subject: Re: [PATCH] BSD Jail LSM (2/3) Date: Fri, 10 Sep 2004 15:23:07 -0500 Attached is a patch against the security Kconfig and Makefile to support bsdjail, as well as the bsdjail.c file itself. bsdjail offers functionality similar to (but more limited than) the vserver patch. A process in a jail lives under a chroot which is not vulnerable to the well-known chdir(...)(etc)chroot(.) attack against normal chroots, and may be locked to one ip address. For additional features, please see Documentation/bsdjail.txt, which is included in the next patch. The patch applies cleanly to 2.6.8.1, and has been tested on xSeries, pSeries, and zSeries. Please apply. Signed-off-by: Serge E. Hallyn [email blocked] -serge [patch]
From: Serge Hallyn [email blocked] Subject: Re: [PATCH] BSD Jail LSM (3/3) Date: Fri, 10 Sep 2004 15:23:51 -0500 Attached is a patch carrying the documentation for the bsdjail LSM. Please apply. Signed-off-by: Serge E. Hallyn [email blocked] -serge [patch]
From: Alan Cox [email blocked] Subject: Re: [PATCH] BSD Jail LSM (2/3) Date: Fri, 10 Sep 2004 20:31:49 +0100 On Gwe, 2004-09-10 at 21:23, Serge Hallyn wrote: > Attached is a patch against the security Kconfig and Makefile to support > bsdjail, as well as the bsdjail.c file itself. bsdjail offers > functionality similar to (but more limited than) the vserver patch. Looking over the code the first question I would ask is that it supports AF_INET but not AF_INET6. That seems a bit limited in todays internet environment. > A process in a jail lives under a chroot which is not vulnerable to the > well-known chdir(...)(etc)chroot(.) attack against normal chroots, and > may be locked to one ip address. For additional features, please see > Documentation/bsdjail.txt, which is included in the next patch. You can break out with someone co-operating from outside the jail but that I guess is pretty harmless anyway. Alan
From: Serge E. Hallyn [email blocked] Subject: Re: [PATCH] BSD Jail LSM (2/3) Date: Sun, 12 Sep 2004 19:33:42 -0400 Quoting Alan Cox (alan@lxorguk.ukuu.org.uk): > On Gwe, 2004-09-10 at 21:23, Serge Hallyn wrote: > > Attached is a patch against the security Kconfig and Makefile to support > > bsdjail, as well as the bsdjail.c file itself. bsdjail offers > > functionality similar to (but more limited than) the vserver patch. > > Looking over the code the first question I would ask is that it supports Thank you for looking at it. > AF_INET but not AF_INET6. That seems a bit limited in todays internet > environment. bsdjail.c in the attached version of jail.diff adds support for ipv6. This was my first time using ipv6, so please let me know if I'm going about it all wrong. Right now one must choose between either an ipv4 or ipv6 interface. Is typical ipv6 usage such that it would be preferable to be able to specify one of each? Compiles and tests on a Crusoe laptop. thanks, -serge [patch]
From: Alan Cox [email blocked] Subject: Re: [PATCH] BSD Jail LSM (2/3) Date: Mon, 13 Sep 2004 11:56:39 +0100 On Llu, 2004-09-13 at 00:33, Serge E. Hallyn wrote: > Right now one must choose between either an ipv4 or ipv6 interface. > Is typical ipv6 usage such that it would be preferable to be able to > specify one of each? Its normal to have both yes. A more interesting question is whether all of the "which socket for which use" stuff could be addressed by netfilter chains run at bind/connect time ?
VServer?
I don't see a point of this over VServer (www.linux-vserver.org). It just seems like a watered down version, perhaps good only if you can't re-compile your kernel.
BSD Jail is useful
As I understand it, the intent is to make a module which resembles a BSD Jail as closely as possible, so people switching from there can reuse their config and don't have to learn about another security module.
Also, in-kernel availability matters, not because of recompiling but because a version for a new kernel is automatically available and you don't end in patch hell.
VServer
so, put vserver-patches into the vanilla-kernel and your done...
vserver is great !
vulnerable to the well-known chdir(...)(etc)chroot(.)
is this currently exploitable in 2.4 or 2.6 kernels? I don't think so or I'm outdated... where there is more info about it?
I supossed that was an old issue
yes all standard kernels are vulnerable to this attack
gr security prevents it too
Why is that a vulnerability?
Why is that a vulnerability? You can't do it if you've dropped root privileges. You dropped root, right?
In fact, I depend on it. It provides useful security--defense in depth--for some master process scenarios. Even qmail depends on this reasonable, expected behavior, iirc.
Why disable renice(2)?
A process can only increase the nice value of other processes with the same uid. What's the problem with that? I would be able to use this patch, but I depend on the program running in the chrooted environment to be able to set some child processes to a lower priority.
DoS
I believe the idea is that you should be able to trust the jail environment to leave the rest of the system alone. Not only is it a security hole to renice an arbitrary process, but renicing even only processes in the jail can still DoS the box.
Re: DoS
How can renicing other processes in the jail DoS the box? The jail
would only be affecting itself... and there's really nothing you can
do about that.
Running as root in jail
I imagine that you'd still be allowed to renice processes in the Jail to *lower* their priority, possibly not to give them higher than normal priority. Obviously you shouldn't be able to do either to processes outside the jail...
Since you may want to run a program as root *within the Jail* (which will be root as far as the jail is concerned but not able to affect things outside the jail), checks on syscalls like this are necessary.
Re: Running as root in jail
Ok, that makes sense. I read it as completely disallowing renice. But I agree that it should be restricted to processes inside the jail no matter what uid is doing the changing and it should be restricted to increasing niceness/lowering priority even for the root user.
Re: Running as root in jail
What about a per-jail "nice offset", i.e., actual nice value of each process is the value visible in jail, plus the offset.
Then, let root in jail run nice with negative value, i.e., increase priority; *but* if resulting priority would be higher than normal, increase offset.
Thus, while in jail it looks you're increasing priority of one process, in fact you're lowering that of all others.