On Fri, 9 Nov 2001, Casey Schaufler wrote: > I'm sorry if it sounds that way. I'm trying really hard to > come to grips with a Linux future based on restrictive hooks > and it's not easy. I had a vision this morning of copying the > entire security architecture into capable(), with historical > checks left in place to placate inflexible maintaners and the > security blob pulsing like an inflated silicon based creature > from a 1950's Ed Wood movie. The C+R scheme circumvents the > intention of the basic design, and while that would allow > ACLs, it does so by deceit, not design. This seems like a misunderstanding. You aren't moving everything into capable - you are just using capable to enable your restrictive hooks (like permission) to act authoritatively. > Stephen has convinced me that C+R can be used to do ACLs. > I look at what it involves, and I say that I would not > condone such in production code. I stick by that. If we > have to do that to get into Linux, well, yuck, but it's > not like I haven't seen other schemes just as convoluted. It doesn't appear to be very difficult at all to implement POSIX ACLs via the C+R scheme. In fact, I would expect the security module to be very similar to one implemented via authoritative hooks. The only difference is that using the C+R scheme requires the module to always return success from its capable hook for CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH and then to recompute the default logic in its permission hook. This isn't so difficult. -- 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 : Mon Nov 12 2001 - 10:39:25 PST