daw@cs.berkeley.edu (David A. Wagner):
> 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/.
yup - user mode isolation of potentially hazardous data. This is where use of
Java is best served - since it was designed to isolate the data. Using the
facilities of ptrace (in any form) is unreliable since that is NOT the purpose
of the interface. It does make a nice prototype and demonstration of what
is desired. At that point you really want a hardware/software supported
process partitioning to isolate the application. That is very similar to
what is done with the dos emulators under linux (or even, linux under
linux...).
> 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.
It is still too slow for a general security interface. There is still two
context switches per event.
> 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().)
It is less than MAC/DAC - it can be bypassed (by the user, not necessarily
by the application), it doesn't scale. MAC labeling scales very well and
cannot be bypassed (depending on the extent of the implementation of course).
A simpler case for sendmail is just to run it in a compartment restricted
to mail handling, only able to write to users mail files and spool files.
If it doesn't have the capability of exec, it can't run poorly done filter
programs.
If you control only sendmail's daemon mode operation it could be restricted to
just the spool files. Everything else is done by a trusted agent to
only read/write the users mail file (a form of the movemail and deliver
utilities). This is much easier to verify.
What you describe is more for a debugging environment where it would be
usefull to trace the process activity in a test/semi production environment.
-------------------------------------------------------------------------
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 : Fri May 12 2000 - 18:28:20 EDT