Date: Sun, 19 Sep 1999 00:07:21 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Jacques Vidrine <n@nectar.com> Cc: Wes Peters <wes@softweyr.com>, security@FreeBSD.ORG Subject: Re: Real-time alarms Message-ID: <Pine.BSF.3.96.990919000136.3012A-100000@fledge.watson.org> In-Reply-To: <19990919024125.817FCBD05@gw.nectar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
One thing one does have to be a little careful about is creating fine-grained access controls with capabilities that are effectively equivilent. For example, allowing direct disk writes is almost always equivilent to allowing direct access to kernel memory, etc. Creating distinct security capabilities can leave the policy creator with false impressinos about the policy they have created. For example, in the Java 1.2 security model, there are a number of effectively equivilent permissions--any permission allowing modification to the security environment is essentially the same--be it the right to make native calls, to modify the class loading behavior, etc. In UNIX, one could see the same effect by creating a capability allowing the binding of privileged ports in arbitrary ways--suddenly previously "secure" environments (NFS, for example) allow the ability to leverage root access. In the case of network examples, there is a strong argument that that is just poor NFS design, but it's something to keep in mind. Similarly, in the POSIX.1e capabilities the ability to send signals to arbitrary processes is often similar to the ability to write to arbitrary files, or read from arbitrary files--they can allow you to subvert security mechanisms. W.r.t. real time alarms--part of my hope for the POSIX.1e auditing code was to provide a general facility for event management and a detection environment so that we don't end up with lots of parallel mechanisms, and also so that we have portable security solutions letting us make use of products for other platforms (linux, et al). Any security sensitive events should certainly be among those audited. On Sat, 18 Sep 1999, Jacques Vidrine wrote: > 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 > 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.BSF.3.96.990919000136.3012A-100000>