Date: Sat, 18 Sep 1999 21:41:25 -0500 From: Jacques Vidrine <n@nectar.com> To: Wes Peters <wes@softweyr.com> Cc: security@FreeBSD.ORG Subject: Re: Real-time alarms Message-ID: <19990919024125.817FCBD05@gw.nectar.com> In-Reply-To: <37E4449B.ADDD68EE@softweyr.com> References: <199909180612.AAA00597@harmony.village.org> <4.2.0.58.19990918093306.047917c0@localhost> <37E4449B.ADDD68EE@softweyr.com>
index | next in thread | previous in thread | raw e-mail
Here's a not-completely-thought-out idea. When looking at PHK's
changes to suser for the jail code, I realized that he had essentially
created two categories of suser calls in the kernel. One category of
calls are allowed if you are NOT in a jail, and the other are allowed
regardless of whether you are in a jail.
I wanted to extend this so that each call to suser passes a category,
kind of like we do with calls to malloc. I wanted to do this for
two reasons:
1) finer granularity of control on what superuser priviledges a
jailed process can use (specified at jail creation time)
2) auditing what superuser priviledges a process has used
or tried to use
e.g. SUSER_SIGNAL sent signals to process we don't own
SUSER_RESOURCE changed our resource settings
SUSER_KLD did something with a KLD
SUSER_REBOOT rebooted the system
SUSER_JAIL made a new jail
etc.
These categories could be as broad or specific as needed, although
one per system call is probably too many :-)
So if I'm running some server application that needs lots of
root priviledges, I don't have to give away the farm.[1]
Thoughts?
Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org
[1] for those who haven't looked at the jail code: it doesn't
give away the farm, either. but the priviledges that can
be used by a jailed process are ``hard wired'' and can't
be customized.
On 18 September 1999 at 20:04, Wes Peters <wes@softweyr.com> wrote:
> This is what we're talking about with the auditing facility. There are
> a lot of architectural issues to be solved, starting with "what is an
> alarm" and ending with "how do I securely transmit the alarms to those
> who need to know about them"?
>
> Fun stuff, eh?
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990919024125.817FCBD05>