On 21 Oct 1999, Dag-Erling Smorgrav wrote:
> Robert Watson <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
