Re: (MAC/DAC) (new idea)

From: David A. Wagner (
Date: Fri May 12 2000 - 13:43:01 EST

In article <>, Matt Yourst <> 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

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
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:21 EST