Re: changing kernsecurelevel
From: Robert Watson (rwatson@FreeBSD.org)
- Next message: Garrett Wollman: "Re: Fw: Re: Antisniffer measures (digest of posts)"
- Previous message: Evan S: "Re: changing kernsecurelevel"
- In reply to: Evan S: "Re: changing kernsecurelevel"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 7 Jan 2001 12:07:57 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Evan S <firstname.lastname@example.org>
On Sun, 7 Jan 2001, Evan S wrote:
> Mm, Openroot runs on -CURRENT, and users are able to apply those flags
> to files. But, I made a little patch, and it seems to work. They're not
> able to do it anymore.
Aha. They can add, but not remove, right? That probably should be
changed -- feel free to e-mail me a patch and I'll apply as appropriate.
> Other than that I'm happy with the way Jail works. The above was the
> only problem I had.
Great. Contributions in this space are always welcome :-).
There is a patch in the PR database, btw, that deals with another problem
with jail() that you might potentially run into: resource limits are
currently global in scope, and not per-jail(). This has positive and
negative aspects, and the patch doesn't address all of the problems that
need to be addressed, I believe. Really, we'd like to have per-jail
resource limits, and then within that scope per-uid-per-jail limits.
However, the current resource mechanism is not structured to support this.
I believe the patch addresses the per-uid-per-jail aspect, but does not
allow the host administrator to specify per-jail limits to bound the
resources allocated to a particular jail. With the gradual cleanup of
credentials and resources limit structures, as well as a possible eventual
move of the jail pointer into ucred or pcred, this problem will probably
be more easily addressed.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
email@example.com NAI Labs, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message