Date: Mon, 28 Aug 2000 09:27:51 -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.1000828091915.83427A-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.0008282356180.11320-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000828091915.83427A-100000>