From owner-freebsd-security Mon Aug 28 6:10: 2 2000 Delivered-To: freebsd-security@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 68AA337B424; Mon, 28 Aug 2000 06:09:44 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id AAA17272; Tue, 29 Aug 2000 00:09:36 +1100 Date: Tue, 29 Aug 2000 00:09:34 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Robert Watson Cc: freebsd-security@FreeBSD.ORG, phk@FreeBSD.ORG, green@FreeBSD.ORG Subject: Re: Review request: replacing p_trespass(), modifications to vaccess() 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 Mon, 28 Aug 2000, Robert Watson wrote: > 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? 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. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message