From owner-freebsd-security Sat Jan 15 8:54:57 2000 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id EF57214C8B for ; Sat, 15 Jan 2000 08:54:49 -0800 (PST) (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 LAA00926; Sat, 15 Jan 2000 11:55:03 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sat, 15 Jan 2000 11:55:02 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: David Pick Cc: freebsd-security@freebsd.org Subject: Re: Restructuring authorization checks to facilitate new security models In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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