Date: Thu, 18 May 2000 10:40:39 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Don Lewis <Don.Lewis@tsc.tdk.com> Cc: Geoffrey Robinson <geoff@grobin.org>, security@FreeBSD.ORG Subject: Re: Jail: Problems? Proper Usage? Status? Practicality? Message-ID: <Pine.NEB.3.96L.1000518103757.25211E-100000@fledge.watson.org> In-Reply-To: <200005172153.OAA01533@salsa.gv.tsc.tdk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 May 2000, Don Lewis wrote: > On May 16, 1:05pm, Robert Watson wrote: > > ... > > } > 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(). I tend to agree. I'm currently working on a design document for a modular kernel policy mechanism that would allow pluggable and extendable security policies, including the capability-limitations associated with Jail. I should be posting a first draft to trustedbsd-discuss and freebsd-security in a couple of days. This would be distinct from virtualization and namespace services, but would be responsible for preventing changes to the virtualization/namespace after it was created and appropriate process properties were configured. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services 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?Pine.NEB.3.96L.1000518103757.25211E-100000>