From owner-freebsd-hackers Thu Oct 21 8:54:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2582114D62; Thu, 21 Oct 1999 08:54:09 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id LAA47948; Thu, 21 Oct 1999 11:54:03 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Thu, 21 Oct 1999 11:54:02 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Dag-Erling Smorgrav Cc: hackers@freebsd.org, security@freebsd.org Subject: Re: Finer-grained securelevel: proof of concept In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 21 Oct 1999, Dag-Erling Smorgrav wrote: > Robert Watson 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