Stephen Smalley wrote: >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. Well, I don't think I can implement Janus on top of SELinux, and I don't think Janus is particular unusual in this regard, so by that measure, I'm not convinced that SELinux is sufficient on its own. (But do correct me if I'm wrong!) I think the reason Linus wanted a truly generic solution is that we security folks can't seem to agree on any One Right Answer to this problem, so he wanted a mechanism that can support everyone's favorite policy. I think this is a laudable goal. >3) Linus also said that he would be willing to accept security IDs >into a number of kernel data structures. I think the right thing to do is include a pointer in appropriate data structures that the rest of the kernel will treat as a pointer to opaque data. In my ideal world, if you want to use that opaque state to hold a Security ID, you can do that, but if I want to use it some other way, I can do so, too. This seems to strictly generalize "Security IDs". And let me say that I don't consider "Security IDs" policy-independent. The type of per-process state that Janus wants to keep is not well characterized as a Security ID. Sorry to harp on about Janus -- I don't think there's anything particularly special about Janus -- but it is the one system that I know very well... _______________________________________________ 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 : Fri Apr 20 2001 - 19:08:05 PDT