Date: Sat, 6 Jan 2001 14:16:53 -0500 (EST) From: Evan S <kaworu@sektor7.ath.cx> To: freebsd-security@freebsd.org Subject: Re: A very quick Jail question (fwd) Message-ID: <Pine.GSO.4.10.10101061416360.4894-100000@wintermute.sekt7>
next in thread | raw e-mail | index | archive | help
Here is what rwatson said to me. :) Evan Sarmiento (kaworu@sektor7.ath.cx) http://sekt7.org/es ---------- Forwarded message ---------- Date: Sat, 6 Jan 2001 10:34:36 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Evan S <kaworu@sektor7.ath.cx> Subject: Re: A very quick Jail question On Thu, 4 Jan 2001, Evan S wrote: > I'm running a project called Openroot, where everyone gets root on a > FreeBSD 5.0-CURRENT computer, (http://www.open-root.org). It is run > inside of a Jail. I'm really a proto-hacker, I havn't made any patches, > or done much work for free software, but I think I know C very well, and > have been looking through some of the Jail source code. I actually logged into open-root a couple of times to look around, it seemed like a neat idea, although it also seemed that people were too willing to blow it away just because they could. > Here is my dilema: > I want users inside of the Jail to not be able to set system immutable > flags on any files. > I want the Jail to run in a different secure level than the host > If the host chflags schg a file in the Jail, a user in the jail cannot > chflags noschg it even though the Jail is running in secure level 0. > > What files would I begin looking at to implement this? Well, securelevels and jail() are really fairly independent creatures, and due to the nature of jail(), securelevels are not really all that necessary. The function of securelevel is to disable certain types of functionality when the securelevel variable is set appropriately; jail() works by disabling successful return of many suser() operations. As a result, jail() is almost always more restrictive than securelevel, in that it restricts most securelevel-restricted operations already. There may be a few isolated calls where jail() permits something unless securelevel is also set, but there shouldn't be many. The only one that comes to mind, actually, is the ability to open a device file -- jail() prevents the creation of new device files by processes in a jail, but doesn't prevent opening existing devices appearing in the jail's file system. securelevel actually limits the opening of devices that already exist. However, as long as you construct your jail properly, you shouldn't need to raise the global securelevel. What we should probably do is go through the kernel and audit all use of the securelevel variable, and determine whether or not those instances are all protected from use within jail(). If you want to take the lead on this, that would be great, as I'm a bit on the over-loaded side right now, and probably won't get to doing this for about a month (and your need appears more short-term than that). I'd be glad to discuss any findings or concerns you have, however. It might also be worth including the freebsd-security mailing list, since I think this would be an issue of interest to others also. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, 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.GSO.4.10.10101061416360.4894-100000>