Date: Thu, 21 Oct 1999 11:54:02 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Dag-Erling Smorgrav <des@flood.ping.uio.no> Cc: hackers@freebsd.org, security@freebsd.org Subject: Re: Finer-grained securelevel: proof of concept Message-ID: <Pine.BSF.3.96.991021114802.47188I-100000@fledge.watson.org> In-Reply-To: <xzpu2nkbv0u.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 Oct 1999, Dag-Erling Smorgrav wrote: > Robert Watson <robert@cyrus.watson.org> writes: > > Very clean, pretty, etc -- only one object: please call it something other > > than capabilities :-). [deletia] > > Please read the thread on -security and -arch that lead to these > patches. I did--hence my comments. My understanding was you did a proof-of-concept to show that doing a bitmasked enabling of system-wide features was feasible and not all that intrusive. And sure enough, it is true (not that I disagreed with you in the first place) I'm objecting to the use of the terminology "capability", and also suggesting that this should become a more general policy query with whatever policy backend you want--i.e., if (!policy_allow(curproc, "kern.socket....")) return(EPERM); The policy manager can then internally represent whatever definition of securelevel it chooses, paying or not paying attention to the passed credentials as it chooses. I'm also suggesting that what we really need is an integrity model and not just a set of feature switches. That is, that a security policy somewhere should describe these relationships between features and integrity of processes and files, and therefore be able to derive from that that certain events should not be allowed to take place--with some help, of course, from information about special files, etc, etc. MAC would be one way of going about doing this. 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-hackers" 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.991021114802.47188I-100000>