Date: Sun, 18 Mar 2001 21:39:05 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: "David E. Cross" <crossd@cs.rpi.edu> Cc: freebsd-arch@freebsd.org Subject: Re: idle wonderings about 'struct pcred' Message-ID: <Pine.NEB.3.96L.1010318213147.51044A-100000@fledge.watson.org> In-Reply-To: <200103190006.TAA44321@cs.rpi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 18 Mar 2001, David E. Cross wrote: > What I want to see happen is the cred strucutures become meta-structures. > They have no data in themselves, but they point to data. Thus I can add This is almost precisely what [is being / has been] implemented. However, there's substantially more involved here in getting the details right, including the goal of not dramatically increasing the performance cost by adding several levels of indirection and abstraction, as well as the significantly complex task of abstracting not just the credentials, but also the access control checks, credential management calls, persistent protection mechanisms, etc. We plan to spend about the next 18 months looking at how best to implement this, using improved modularity in the credential/labeling/authorization mechanism to improve the assurance properties of the code, etc. There's a lot of work to getting this right. The first steps have consisted of moving existing authorization structures into struct ucred (such as the jail data, a change that has occurred in -CURRENT but not -STABLE), allowing the kernel ucred structure to be different from the userland ABI ucred, improving security abstractions and consistency, improving kernel object labeling, and implementing new security models so that we know the basic requirements for a more general mechanism. Generally speaking it's bad to come up with new abstractions without having a fair number of examples from which to abstract, and if the goal here is extensibility *beyond* the basic UNIX credential types, then we need to have implementations of other types to work from (you can find implementations of three MAC schemes and process capabilities on the TrustedBSD site). BTW, the cost of having a cleanly abstracted credential interface is *far* higher than the cost of the current jail pointer on each process. :-) Also, we need a number of the serious structural changes associated with SMPng (such as synchronization primitives and proc locking) to be finished before we can do a lot of this work. We're targetting a modular and general authorization framework at FreeBSD 6.0-RELEASE, with the goal of having run-time pluggable support for a number of these security add-ons. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" 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.1010318213147.51044A-100000>