Date: Wed, 17 May 2000 14:53:13 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Robert Watson <rwatson@FreeBSD.ORG>, Geoffrey Robinson <geoff@grobin.org> Cc: security@FreeBSD.ORG Subject: Re: Jail: Problems? Proper Usage? Status? Practicality? Message-ID: <200005172153.OAA01533@salsa.gv.tsc.tdk.com> In-Reply-To: <Pine.NEB.3.96L.1000516125854.15891D-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1000516125854.15891D-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 16, 1:05pm, Robert Watson wrote: } Subject: Re: Jail: Problems? Proper Usage? Status? Practicality? } On Mon, 15 May 2000, Geoffrey Robinson wrote: } > aware that raw sockets are not allowed to jailed processes but is there } > a workaround for ping and traceroute? } } Currently, no. Due to the way raw sockets work (allowing listening for } all non-handled IP messages, and allowing direct writing of IP packets), } it would take a bit of work to get this up and running, although it would } be feasible. A more promising long-term goal might be to better } virtualize network services, creating virtual interfaces and binding real } network resources to virtual interfaces. I think this is the right way to go. The current jail implementation is not compatible with IPv6, and there is no way to confine a dual homed proxy server to a jail, since the jail is only allowed one IP address. If the jail used virtual network interfaces, then it would be possible to add packet filter rules to these network interfaces. This would be much more flexible than the current implementation, since it would then be possible to have fine grained control over the network connections allowed into and out of the jail. It would also be possible for multiple jails to share the same IP address but be restricted to disjoint port ranges. } > Finally how secure is jail really? I'm aware of a trivial chroot breakout } > technique. Does that hole still exist? Are there any other known holes? Is } > jail still under active development? Is it worth the trouble to do any of } > this? } Right now my efforts are primarily aimed at improving the security } abstractions within the kernel relating to the TrustedBSD project--this } should have a side benefit of improving the relationship between jail() } and the base OS, making Jail easier to maintain and modify. I think this is also the right thing to do. I would go so far as to deprecate the jail(2) syscall, and implement jail(8) in terms of the syscalls to set up the virtual network interfaces, the syscalls to set the process capabilities, and chroot(). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005172153.OAA01533>