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. I think there's confusion due to different meanings of "generic solution". Yes, SELinux separates policy from enforcement, but it does impose a set of policy models (Type Enforcement, RBAC). I think Linus' view of "generic solution" is much more draconian, where "generic solution" includes *no* solution, i.e. kick security to the curb if you don't want/need it. > 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. I'm reasonably sure that this is not what is wanted in a "generic solution". Rather, the generic solution should enable SELinux or RSBAC to be employed if desired. > 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. I've taken the position that we should include only hooks for modules that seriously intend to port to the LSM interface. I would love it if SELinux and RSBAC became LSM modules. So the above is entirely consistent with my view of this project's goals. However, I have been told that the SELinux people doubt the viability of a LKM interface for their package, and I've seen the RSBAC people claim in public that they don't believe that LSM is sufficient for their needs. So, I advocate LSM providing the hooks for SELinux and RSBAC if and only if they intend to port to it. > 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. This is a serious issue. Should there be an LSM-wide standard for security IDs? Or should LSM security IDs just be opaque blobs, and semantics are imposed by the LSM module that is installed? I have a hard time convincing myself that we've seen the last word in security IDs. That plus the above stated fact that RSBAC and SELinux uses different notions of IDs suggests that we should go with opaque blobs. > 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. My main problem with that is that SubDomain is 1/10th the size of SELinux. Parsimony is its main advantage over more general MAC systems, so forcing SubDomain to sit on top of another MAC system destroys its value. Yes, you can use an 18-wheel truck as a commuter vehicle, but it's not always the best solution. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org _______________________________________________ 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 - 14:55:20 PDT