Matt Yourst <yourst@mit.edu>:
> Here's an idea I had regarding the future Linux security architecture, reading
> the comments made in this thread. I propose the use of a trusted user-space
> process in conjunction with kernel caching of policy decisions to implement a
> flexible and very secure system:
>
> Let's say each file (and other kernel things that currently use POSIX-style
> security) could be associated with some opaque identifier (for instance, a
> 64-bit "policy token", token) that would reference an ACL. Such identifiers
> could and should be reused *only* between identical ACLs (see why below.) Now,
> the first time a given token must be checked for a given user/permissions
> request (i.e. file open), the kernel would send a message like the following to
> a special user-space process (the security daemon):
>
> ssp_approve(policy_token_t token, uid_t uid, int requested_access)
>
> The daemon would then determine whether or not to grant the access, and return
> one of GRANT, DENY, AUDIT, etc. back to the kernel. Before doing anything else,
> the kernel would add this decision to some kind of hash table with {token, uid,
> request} as a key and {GRANT/DENY/AUDIT/...} as a value. The next time any file
> or object with the same ACL (and hence, the same token!) must be checked, the
> kernel needn't talk to the user-space daemon - it can just return the cached
> decision (unless it has to audit a repeated failure of course.) This would be a
> *big* speed-up, given that a given user typically only has a handful of
> *different* ACLs spread over all files they own. This is especially true for
> things like web servers, since the server may go for months without a
> kernel<->security daemon request being needed.
>
> However, why would we do this in user-space instead of just right within the
> kernel? Because it's more secure, *much* more flexible, and just as efficient
> (due to the caching mentioned above.)
>
> As far as security, this means less kernel code to have bugs and a user-space
> process is isolated and restartable if compromised (both in line with the
> earlier comments about microkernel OS's being provably more secure.) We could
> also arrange to have the security daemon be sort of a "watchdog" process - if it
> gets killed, fails to start, is compromised or malfunctions in any way, NO
> access to ACL-protected files would be allowed (except by local root login, to
> restart it.)
>
> For flexibility, think of the success of the current PAM module system used for
> login authentication. We (or people with even more stringent security
> requirements) could implement the user-space daemon as required, as long as it
> worked with the kernel protocol. Besides, it could do things that the kernel has
> no business doing (for instance, "time-based access checks, origin-based
> control", etc. - quoting direct from the NIST/ISO requirements document
> mentioned in this thread.)
>
> However, there are two challenges with this approach: (1) how to store the ACLs
> themselves and associate them with tokens, and (2) how to make the kernel and
> the user-space process atomic (journaling?) to prevent orphaned ACLs and all
> kinds of other problems. The first issue could be handled directly by some of
> the new filesystems on the horizon (in particular, I'm thinking of ReiserFS),
> and the second doesn't seem to be that difficult to solve.
>
> (Side Note #1): Whenever we set or get the actual *data* of the ACL (i.e., for
> backups, NOT for kernel-based file open authorization), another message would
> need to be sent to the security daemon. It would then determine whether or not
> an existing token referenced the byte-for-byte identical ACL structure, and if
> so, it would return this data (otherwise it would internally allocate another
> ACL.) Fortunately, these operations are fairly rare and could be optimized (file
> creation at least) by kernel caching. A mechanism for invalidating kernel cached
> ACLs/tokens would also need to be implemented.
>
> (Side Note #2): It seems that this technique has already proven effective in
> other so-called "trusted" OS's, as well as in NT (although I wouldn't exactly
> "trust" it, apparently it got through the standards review since it DOES run
> LSASS (aka "local security authority") as a separate process like the one
> proposed here.)
>
> Granted, I'm not an expert on provable security, but might this be a good way to
> meet the toughest standards? Comments on this, anyone?
Not new, It came up some time ago. The problem is that the daemon must
respond - this calls for two context switches for many (most?) system calls.
open, close, exec, ioctl, FIFO, socket, send, recieve, bind, ...
Second, the daemon must not be bypassed. Now consider the speed of SMP
processing of user applications. Only the kernel can perform the checks
at this rate. Now mind, most of the MAC checks are trivial - (much simplified)
1. is the subject level OP object level, where OP is greater, less, equal.
it depends on some context information as to what to do with the result.
2. is the subject compartment dominate, equal the object - where
dominate means at least the same compartments plus other compartments
and equal means the same compartments.
3. Do the capability flags permit the operation.
After that are the descretionary controls. Most of these are already
implemented, only ACLs are not current. There are several patches available
that make ACLs available in EXT-2.
The major effort is in maintaining the current labels in memory of all active
subjects, and retrieval of labels in objects (other systems store them in
process headers and inode headers making them available via direct address
or index).
Implmentation of the MAC tests usually require a collection of code to be
a "reference monitor" that guarantees the tests are made (and logged), and the
drivers/system calls provide the enforcement. The advantage of the separation
into a "reference monitor" is that the monitor could be dropped (as a
configure option) and the system would run in the current "root priveleged"
mode.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:15 EST