Matt Yourst <yourst@mit.edu>
> 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.
As soon as you cache, you get a failure because the permissions may change
during the lifetime of the cache. Second, where are you cacheing? Obviously it
is in the kernel (since it must make the decision, right?) If it is in the kernel
then you don't need the daemon anymore except for retrieving the necessary data.
Since this information must already pass through the kernel to give it to the
daemon, why do it twice?
> >
> > 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?
The "not bypassed" is to make it possible to verify that any activity aginst the
subject/object takes place in all places the subject/object exists - cache and daemon
simultaneously. If it doesn't then a decision that was previously valid may be used
when it has been invalidated (in short... cache synchronization with the daemon).
You also have the possiblity that the daemon is getting attacked externally (killed
and restarted type of thing).
Again, if the cache is in the kernel, and the log capability is in the kernel, then
you have already implemented the functions in the kernel. The daemon is not needed.
> >
> > 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.)
Ext 2/3 already have the fields, and Ext2 has a patch that actually implements them.
> >
> > 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.
It already is very flexible - only the enforcement functions are in the kernel.
The rest of it is table driven where the table is accessed via definitions stored
for subjects (the process header information via the process table) and the
file system inode data. The choice is done by the bit settings in each inode.
The cached object information is loaded into the kernel when files are accessed -
either from namei lookup, or getinode functions. Any changes to objects
occur via the cached entries anyway (ie. chmod type of things) it automatically
updates the table... and no disk/daemon activity required beyond the currently
exiting file system updates.
It does require some changes to fsck to protect the MAC labels applied to the
files.
Policy is implemented by setting the chosen bits on the inodes in the filesystem.
-------------------------------------------------------------------------
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:19 EST