Date: Mon, 28 Aug 2000 08:33:26 -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.1000828082839.83018A-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.0008282029490.11108-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Aug 2000, Bruce Evans wrote: > On Sun, 27 Aug 2000, Robert Watson wrote: > > > I've put up a patch that makes fairly extensive changes to the structure > > (but hopefully not the semantics) of inter-process authorization checks: > > > > http://www.freebsd.org/~rwatson/p_stuff.diff > > Most of this seems reasonable. > > > 3) Modify vaccess() so that it is restructured for more careful/ordered > > use of privilege, and so that capability support can be added more > > easily. This should be semantically the same from a results > > perspective, but it is more careful to do a discretionary access > > check before falling back in privilege, et al. As such, the KSU > ASU? > > accounting bit will now be set correctly in vaccess() for processes > > running as uid 0, if they use privilege to access a file rather > > than discretionary rights. > > vaccess() currently intentionally doesn't set ASU, since checking for > access doesn't require any privilege. ASU should only be set if > privileged access is used, e.g., upon successful completion of an > open(2) call that needed privilege to succeed, but never for access(2). In the various p_can* calls, I have a *privused argument, intended to allow the caller to determine whether or not privilege would be used to perform the access authorized by the pcan* calls. In my capability tree, the ASU flag is not set by suser(), rather by an independent suser_used(p) call, which is called based on a cumulative privilege flag, once some part of the operation commits persistently. The same technique could easily be applied in vaccess(). However, I have received comments from a number of people that the ASU flag introduces more complexity than it is worth: they'd rather see reduced structural complexity, and lose the ASU flag. In any case, I'd like to see suser() used in vaccess(), centralizing the super-user decision, regardless of whether ASU is provided for, meaning that to correctly maintain ASU, it must not be set in suser(). With that reasoning in mind, do you think ASU can be {temporarily, permanently} deprecated/broken? 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.NEB.3.96L.1000828082839.83018A-100000>