Here is what rwatson said to me. :)

Evan Sarmiento (kaworusektor7.ath.cx)
http://sekt7.org/es

---------- Forwarded message ----------
Date: Sat, 6 Jan 2001 10:34:36 -0500 (EST)
From: Robert Watson <rwatsonFreeBSD.org>
To: Evan S <kaworusektor7.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
robertfledge.watson.org NAI Labs, Safeport Network Services

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]