Date: Mon, 28 Aug 2000 13:16:34 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-security@FreeBSD.ORG, phk@FreeBSD.ORG, green@FreeBSD.ORG Subject: Re: Review request: replacing p_trespass(), modifications to vaccess() Message-ID: <Pine.NEB.3.96L.1000828131039.84062M-100000@fledge.watson.org> In-Reply-To: <Pine.NEB.3.96L.1000828091915.83427A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I've uploaded a new version of the p_stuff.diff patch (http://www.freebsd.org/~rwatson/p_stuff.diff) that adds the following changes: 1) Eliminate ASU being set in suser_xxx() 2) Change suser{,_xxx} and p_can{see,kill,sched,debug} to use const struct *{cred,proc} 3) Modify vaccess() to accept an additional argument, in the style of p_can*, *privused, which can allow the caller to determine if privilege was required for vaccess() to return 0. 4) Change EPERM back to EACCES when vaccess() fails, as it's a failure due to DAC permissions, not a failure of privilege at this level. 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 On Mon, 28 Aug 2000, Robert Watson wrote: > > On Tue, 29 Aug 2000, Bruce Evans wrote: > > > > With that reasoning in mind, do you think ASU can be {temporarily, > > > permanently} deprecated/broken? > > > > I think it should be permanently dropped from normal kernels, but your > > work seems to require even more flags like it, at least for debugging. > > I'm not sure how well complexity for extra security can be localised. > > My main concern at this point was whether or not ASU could be dropped from > the base system. You're right of course: eventually, I hope to handle > auditing of privilege, just seperately from the current use of the > accounting system to do that. We've gone through a couple of partial > implementations of auditing on FreeBSD, and I've had the opportunity to > consider similar systems on other platforms, and have yet to see an > implementation that satisfies all my concerns (in terms of correctness, > cleaness of integration et al). I'm tempted to put off dealing with that > until we've had a chance to look further at the impact of authorization > improvements in the system, although presumably avoid explicitly breaking > the possibility of adding it easily :-). > > I'll update my patches to include the removal of ASU from suser(), which > would then allow suser() to accept const proc * and const cred *, which > will remove qualifier warnings elsewhere in the tree. > > I'd like for us to move in the direction of only requiring const struct > cred * for access control decisions, but right now that's not possible due > to the use of P_SUGID in struct proc's flags. One question to ask then is > whether or not P_SUGID could be moved into a set of credential flags, > reflecting that state of the credentials. Doing so would impact the use > of crcopy() and friends, and also require that it be explicitely unset > following an exec() of a non-setugid binary (presumably -- I haven't read > through the details of P_SUGID semantics). With the advent of > capabilities that are independent of uid0, it strikes me that the > requirements are actually for multiple flags: one that indicates a change > in privilege or credential over the lifetime of the process, requiring > protection of the process from certain types of operations (ptrace, et > al). The second would be a cached indication of having privilege > available: be it via uid0 providing that privilege, or via holding > capabilities, et al. If fast enough, this need not be cached, of course. > > 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 > 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.NEB.3.96L.1000828131039.84062M-100000>