Jesse Pollard wrote:
>
> 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:
> >
>
> 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, ...
>
I agree that this is not very efficient if done on every syscall, but with
caching I don't see why it would even need to be done every time. After all,
there are a much smaller number of possible permission combinations than files.
For instance, my home directory has roughly 30000 files owned by me. Over half
(17300) of these have mode 640 (rw/r/-); basically there are only two or three
unique permission types over all 30000 files. Thus, after I log on and access a
few files, it seems that the kernel would only have to get a decision from the
daemon two or three times; every other time, a cached decision could be used.
>
> Second, the daemon must not be bypassed.
>
I assume you mean "not bypassed" as in caching policy decisions would not work.
Why is this, assuming that the cached decision result also includes an "audit on
cache reference" flag and some method for invalidating the cache?
>
> Now consider the speed of SMP processing of user applications.
> Only the kernel can perform the checks at this rate.
>
In certain cases, I see your point. Actually, after posting this idea, I started
wondering about the performance implications of this myself. As you mentioned,
on SMP systems, we'd have major performance problems if a single kernel/daemon
pipe was used for everything (e.g. what if the daemon had to wait for a mmap'ed
page of the policy/ACL database to be read - the whole kernel could stall.)
There are certainly ways around this (in particular, using a Mach or NT-style
local procedure call port); it turns out that NT does use this method to talk to
LSASS about certain policy decisions. However, I agree that this approach is one
of the reasons NT might be so slow compared to kernel-based reference monitors
like in Solaris, etc.
>
> 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.
>
It's unfortunate that ACLs are not a more generalized part of the kernel like
capabilities are now - it's probably a bad idea to reinvent the wheel for every
filesystem. On this note, I'm considering making a patch to ReiserFS to allow
storing POSIX-compliant ACLs as native "item types" - this way, all of the new
"next generation" filesystems for Linux will have uniform ACL support (XFS
already does, and I believe that IBM's JFS code does too.)
>
> 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).
>
I do agree fully here. It might be more trouble than it's worth to track all
these things atomically (especially if ACLs are shared amongst multiple
objects.) Just storing security information in the relevant filesystem with its
inode is more straightforward.
>
> 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.
>
The major goal of a user-space system would have been flexibility: somehow I
can't see the kernel doing very complex policy decisions itself (especially
time-based authorization or anything that must consult another server over the
network for permission or even encryption keys.) Still, if we have a clearly
defined policy engine interface, security level specific kernel modules could be
loaded as needed. Even if a user-space daemon isn't the best idea, we might
still consider storing opaque identifiers in inodes instead of specific ACL
structures. These would allow more flexibility in the future if any additional
MAC/DAC controls above needed to be integrated.
- Matt Yourst
-------------------------------------------------------------
Matt T. Yourst Massachusetts Institute of Technology
yourst@mit.edu 617.225.7690
513 French House - 476 Memorial Drive - 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:18 EST