Date: Sat, 15 Jan 2000 11:55:02 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: David Pick <D.M.Pick@qmw.ac.uk> Cc: freebsd-security@freebsd.org Subject: Re: Restructuring authorization checks to facilitate new security models Message-ID: <Pine.BSF.3.96.1000114160921.39033A-100000@fledge.watson.org> In-Reply-To: <E1299gy-0005rl-00@xi.css.qmw.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Jan 2000, David Pick wrote:
> The subject/object model looks reasonable, but I suspect that some
> operations will turn out to have more than one object operand; for
> example a user/process (subject) mounting (operation) a file system
> (object) at a particular place in the already mounted filesystem
> (second object).
I was wondering about this (and mentioned it as a possibility) but was not
clear on specific examples where multiple objects were needed--in most
cases this can be safely decomposed into two access checks, one per
object.
However, this continues to raise the issue of whether or not such access
checks should be specific to individual requests, or whether they should
be generic categories ("WRITE", "READ", ..). I'm leaning towards
categories as it allows more extensibility with introduction of new
syscalls, etc.
> I also suspect that the exact choice of which subject to use will not
> always be obvious; in my example will it be the user or the process? -
> the criteria about what object should "inherit" what capabilities from
> what object and be controlled by any ACLs tagged on to which object will
> be a good generator of (ahem) debate.
Presumably the credential block would resemble the existing ucred
structure, maintaining uid/gid information, whether or not the process
should be protected from ptrace/etc, a capability mask, and so on. As you
point out, generalizing access checks also suggests generalizing some
common points for transforms -- i.e., inheritence on exec. Presumably
some things can't be generalized--for example, picking up privileges on
exec from setuid binaries, transfer of rights via ancillary data on a
socket (especially in the style of my tokens code where you can delegate
the use of tokens). Similarly, we'll have to think through a way to
notify the authorization subsystem of security events--MAC would require
label changes on successful events, for example.
One nice thing about providing a decent set of hooks and generalizations
is that we could now have pluggable authorization modules--for example,
FreeDTE could be dropped in with a kld at runtime, rather than having to
be compiled in. Similarly, MAC, an otherwise extremely intrusive set of
changes on the base source tree, could be slipped in with relative ease.
Being able to say "load these kernel modules to get B2-targetted
behavior" would be pretty impressive :-).
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.1000114160921.39033A-100000>