On Wed, 18 Apr 2001, Crispin Cowan wrote: > 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. I think that this is a misunderstanding. SELinux doesn't impose any set of policy models. We do provide an example security server that happens to implement TE, RBAC, and optionally MLS, but that is just an example. Our goal was to gain acceptance of the SELinux architecture and interfaces. The example security server is merely a demonstration of how the architecture and interfaces can be used to support various security policies. SELinux can easily support the "no security" option by replacing the security server. And it wouldn't be so terribly hard to replace the example security server with a primitive core for bootstrapping that is then replaced by a loaded module with the full policy logic. > 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. This is a terribly irresponsible approach. As I've mentioned before, we have two working example systems based on significant prior research that already provide security in a very general manner. To ignore them just because they have some concerns about the direction of this effort is unwise if you really want a good solution. The SELinux control points and interfaces are all thoroughly documented and available on the web site already, so there is really no excuse for not considering them. The real problem here is that you are rushing to a solution without taking the time to think it through first. > 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. In SELinux, security IDs are opaque integers that can only be interpreted by the security server. If you choose to instead use void*, then it probably doesn't matter much. > 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. I'm not suggesting that you implement SubDomain via SELinux. I'm suggesting that if we were to start with systems like SELinux and RSBAC in developing our set of hooks, we would end up with a set of hooks that could easily support SubDomain and other projects. -- 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
This archive was generated by hypermail 2b30 : Thu Apr 19 2001 - 05:42:08 PDT