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?
- Matt Yourst
-------------------------------------------------------------
Matt T. Yourst Massachusetts Institute of Technology
yourst@mit.edu Cambridge, MA 02136
-------------------------------------------------------------
-
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:14 EST