Crispin Cowan wrote:
>There is extensive security theory that shows that composition of
>security policies does not generalize [...]
Sure, but we want to do this in practice, so I'd be happy if we can
allow composition of policies in the common case, even if we don't have
a general solution.
In general, interposition gives a few issues: e.g., if multiple
modules want to interpose on the 'foo' event, which order do you
call them in? However, this might not come up in the common case.
There are a few things we can do to make it more likely that security
modules will play nicely. For instance, here are a few thoughts:
- For each event 'foo', allow modules to register before_foo() and
after_foo() hooks. If multiple modules are interested in 'foo',
the kernel will make multiple before_foo() calls (one per module).
- Allow apps to register a check_foo() hook that is called before
'foo' and can return either ALLOW or DENY, and use some semantics
for combining responses, e.g., "If any module returns DENY, the
event is blocked".
Note that the above interfaces are pretty good for composition.
Observe that we need not rule out allowing apps to interpose on events.
I'm simply noting that an important common case is passive filtering
and passive monitoring, and these common cases allow for clean
composition, so we should design interfaces that encourage developers
to use the composition-friendly mechanisms whereever possible.
By the way, it's worth thinking carefully about side effects: this
is one area where (in hindsight) I would have done Janus differently
if I know then what I know now. A few suggestions:
- Warn module developers that before_foo() hooks could be called in
any order (so don't rely on the order in which modules are called).
- Forbid side effects in check_foo(). If modules want both ability
to filter 'foo' events and to take side effects (e.g., count occurrences),
then they should register both a check_foo() and a before_foo()
hook, with filtering in the former and side effects in the latter.
The security kernel should call all check_foo() hooks first, then
decide whether to allow the event, then call all before_foo() hooks
only if it has been allowed.
All of the above is just brainstorming and random ideas (which may be
bad ones for all I know). Feedback and criticism is welcomed.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:15:26 PDT