On Tue, Feb 01, 2000 at 12:22:55AM -0600, Dan Potter wrote: > >] apropos jail > jail(2) - Imprison current process and future decendants > > This is different, it's a FreeBSD 4.0 kernel-based thing. It's much more > powerful than chroot but similar. It's chroot plus it restricts root's > capabilities and makes only processes in the same jail and one IP address > accessable. I'm guessing this is for building virtual machines under a > main machine, which is what we're doing where I work...
Hmm... chroot plus constrain ip, plus per-process syslevel. I don't know how to tackle the ip addr lock down. I'm sending email to someone who does -- hopefully he'll tell me. Most of the work has already been done to constrain root under linux. You'd need to change the definition of cap_set_full (a #define in <linus/capability.h>), to use a mask which is kept in ->current, and you'd need to add a syscall to reduce the set of priviledges in the mask. If you could confirm that the capabilities in <linux/capability.h> are relevant to the needs of jail, I could go ahead and write up a patch that implements this feature. > > > Things like 'ps' and 'top' use BSD-specific methods since the POSIX > > > committee in all their wisdom decided against specifying a way to > > > introspect the system. So you'd need these too. > > > > It's not so pleasant if independent versions of such things have to be > > resupplied for every kernel. Do they? > > Unfortunately, yes. That's the kernel dependencies I was talking about > working around (and that the other Dan was talking about). Ok, so for BSD there would have to be a kernel release specific set of such binaries. This should still be quite a bit smaller than everything that's in /usr/bin/ on a BSD system. Might be worth having a release-specific directory which could underly the debian /usr/bin/ -- this would allow reboots across kernel releases without having to worry about package installs. Thanks, -- Raul
