On Wed, Apr 18, 2001 at 04:49:27PM -0400, Stephen Smalley wrote: > > 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. How about all of the groups looking at the currently proposed hooks and see if they meet their needs? I have taken a look at both SELinux and RSBAC to see what they need, but we need feedback from everyone on this, instead of a few people guessing what others needs. I'd be very interested if someone can convert the current SELinux or RSBAC interface to meet Linus' style. That's what we have done for SubDomain and Capabilities with the currently proposed model. Please do this, or tell me what is lacking from the current model. > 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. Large numbers of hooks are great. The more the merrier! I don't think anyone has proposed a hook that isn't in Chris's header right now (with the exception of a few of the LTT proposals, which I'm still looking at.) I sure haven't been turning anything away. > 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. Using void * on numerous kernel data structures should be able to handle everyones needs for security ids to follow these data objects. A list of the objects that SELinux currently hooks off of would be wonderful as it looks like SELinux currently has the most mature, expressive, and fine grained implementation right now. I really want SELinux to be able to fit into this model. > 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. Layering things isn't necessarily the best proposal. Lots of people have spoken out against it and I've proposed a way for everyone to use hooks out of different security modules if they want to (the logic for doing this goes into that specific security module, for instance SubDomain will be calling the Capabilities hooks before doing its own checks.) Let's get the "simple" version with no layering working first before people go worrying about that :) Thanks a lot for posting, looking forward to working together. greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Wed Apr 18 2001 - 18:37:20 PDT