Direction of the mailing list/effort

sdsat_private

I'm concerned that the direction of this mailing list/effort is rather
far from what was originally requested by Linus.  Let's back up for a
moment to Linus' original message.  

1) Linus said that he wants a truly generic solution.  Now, I could
argue that SELinux already provides a truly generic solution - it is
already the case that SELinux cleanly separates policy from
enforcement, and it can support a wide range of security policies.
The architecture of SELinux has been experimentally validated in
several prior prototype systems (Flask, DTOS, and DTMach), and several
formal studies have been performed of its security, assurability, and
flexibility.  The RSBAC folks could probably make some similar claims
for their system, since their work draws from a paper by LaPadula
based on Abrams' Generalized Framework for Access Control.  So we have
two working example systems today that go a long way toward this goal
and that are based on a significant amount of research and
development. I understand that neither SELinux nor RSBAC provide quite
the style of interface that Linus wants.  But if you want a truly
generic solution, it makes more sense to convert the SELinux and/or
RSBAC interface to meet Linus' style than to start from scratch and
have to re-argue about every hook.

2) Linus said that he would be willing to entertain the notion
of a large number of hooks in the kernel (he mentioned the number
140 without objection in his first message, and 200 in his
second message).  That suggests that rather than being minimalist
in developing our set of hooks, we can indeed take the set of
code insertion points in existing systems like SELinux and RSBAC
and define hooks based on them.  That allows us to provide
comprehensive and flexible security and lets us leverage
all of the prior research and development that has already
gone into SELinux and RSBAC.

3) Linus also said that he would be willing to accept security IDs 
into a number of kernel data structures. Security IDs, if you're not 
familiar, are a policy-independent data type for security labels 
already used in SELinux.  We already know what data structures need 
security IDs for SELinux, since it is already implemented.  RSBAC
used a different approach (using separate mappings for binding
labels to subjects and objects), but they could probably easily 
generate a list of the data structures they would like to be able
to directly tag.  

Based on Linus' message, I would think that the natural way to respond
would be for projects like RSBAC and SELinux (and possibly others) to
(preferably cooperatively but if necessary competitively) define the
set of hooks that they would need based on their current code
insertion points and to move their existing implementations behind
these new hook interfaces.  Since both RSBAC and SELinux are already
quite general, I doubt that we would have any problem with
implementing POSIX.1e capabilities, LIDS, LOMAC, SubDomain, CryptoMark
and other schemes behind those same hooks.  This approach will produce
a truly generic solution that is both flexible and secure and that can
satisfy all of the projects.  There is no reason to think that Linus
will reject it, since he has expressed a willingness to consider a
large number of hooks and since he wants a truly generic solution.

--
Stephen D. Smalley, NAI Labs
ssmalleyat_private

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module