Date: Fri, 14 Jan 2000 08:08:25 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: freebsd-security@freebsd.org Subject: Restructuring authorization checks to facilitate new security models Message-ID: <Pine.BSF.3.96.1000113200906.33318B-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
Hi there folks, As you most likely know, I've been involved in a number of projects relating to extending or replacing the base FreeBSD/BSD security model for a variety of purposes, be it integration with distributed systems, or trusted system extensions for FreeBSD. One recurring theme has been that the first thing to be replaced are the calls to suser(), problems managing object security parameters, extending pcred, etc. I'd like to propose that we discuss modifying the current structure a bit to improve the extensibility of the security model, enabling projects such as FreeDTE, trusted OS extensions such as POSIX.1e, etc, to be implemented more easily and less intrusively. Almost all authorization mechanisms fall under the generalization that they involve some subject (process) performing an operation on one or more objects (process, vnode, network interface, ...), which may in and of themselves be the subjects of other operations. For example, currently with the privileged uid 0 behavior, almost all checks involve simply a subject, and an implicit operation, with little regard for the object (suser()). With file permissions, all of these are taken into account: a subject, an object, and a specific operation checked against a permission mask (or ACL). With signal operations, again there are subjects and objects, both of which are processes. Mandatory access control, capabilities, and DTE all fit well into this model. As such, a basic security operation usually looks a little like this: access_check(subject_label, object_label, operation_descriptor) Which would return a boolean descriptor. In the case of MAC or information flow labels, the object_label or subject_label would be modified as a result of this operation. The best approach may simply be to define a generic, extensible security label with the desirable features -- uids, capabilities, MAC labels, etc. Then replace existing permission structures with these. For example: if ((error = access_check(p1->p_seclabel, p2->p_seclabel, ACCESS_PKILL)) return (error); if ((error = VOP_GETSECLABEL(vp, &seclabel, p, 0)) return (error); if ((error = access_check(p1->p_seclabel, &seclabel, ACESS_WRITE)) return (error); You could imagine a more extensive ACCES_ component that described the operation as part of a hierarchal set of operation descriptors, etc, etc, but you get the idea--a constant suffices for this example. In the case of normal UNIX-like operation, this call would result in an ownership check, a suser check, and a capability check. With MAC enabled, there would also be an overriding MAC label check, etc. I.e., this call would demux in a centralized policy engine that could implement a variety of policies in a pluggable way--possibly even pluggable at runtime using klds. You could imagine a simple boolean evaluation tree merging policy results from various policy modules to produce a consistent combined policy based on allowing capabilities, relying on MAC, and permitting a superuser, for example. Similarly, you can imagine pulling the superuser support at runtime, or adding securelevel modules that introduce masks on available results. Some unfamiliar objects would also be assigned labels for security processing--interfaces, IPFW configuration, ... Anyhow, this functionality would be very useful to me, and a number of others working on security-related projects in the kernel. I'd like to get feedback and discussion on the set of checks that could be adapted to such a format, and their requirements--i.e., are all checks going to involve two labels? What kind of material should be in the seclabel (prison, uids, gids, capabilities, mac labels, inf labels, extensible pointers...?), etc. Presumably a proc pointer is also required to allow scheduling of events (i.e., to read policy from userland or a file, etc). Is this kind of generalization one that would be useful to commit to the central repository? It would certainly make maintaing a mandatory access control implementation easier, as normally such an implementation requires fairly intrusive hooks throughout the OS, but this call is a generic form of those hooks. Any comments or suggestions would be much appreciated--I'd like to start work on an implementation ASAP (i.e., in the next two weeks) so I can push a number of new security models out the door. 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.BSF.3.96.1000113200906.33318B-100000>