In article <391B0115.80E4E564@mit.edu>, Matt Yourst <yourst@mit.edu> wrote:
> 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.
Yes, yes, yes! A little kernel support seems to go a long way here.
I've done some work on user-space daemons that do interesting policy
decisions, by interposing on the system call interface. This approach
seems really powerful. Unfortunately, the system call interface is not
ideal for these purposes; but fortunately, not too much more would be
needed from the kernel to do this right. If you want to read more on
what I've done, see http://www.cs.berkeley.edu/~daw/janus/.
It seems that there are two things the kernel could provide which would
make this approach more convenient:
1. A better event-communication interface.
ptrace()'s use of signals is really pretty awful (what a kludge),
and the inability to specify which events you are and aren't interested
in limits its usefulness.
2. Ability to interpose on other security-relevant events.
I'm thinking especially of filesystem events -- if the user-space
daemon could store a flag on inodes of interest and receive an event
each time such an inode is accessed, this would go a long way.
Please don't hesitate to email me if you'd like more information.
Note that this goes beyond MAC/DAC, and in particular is of interest for
"jail"ing untrusted or semi-untrusted applications. (Think of sendmail,
for instance; the above lets you build a better chroot().)
-
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:21 EST