Stephen Smalley wrote: > 1) It is likely to be politically difficult to gain acceptance > from the Linux kernel developers for such pervasive and significant > changes to the Linux kernel. No. This is wrong thinking. Every commercial security effort has tried the "first do no harm" approach, and the results have been universally atrocious. Let's face it. If we as a group cannot push the LSM agenda past the cycle-counters and the code screw-up cowboys then we have no business in the Linux kernel. Somebody is going to whine about any change that goes in. > It seems wiser to go for an incremental > approach - first gain acceptance for a set of new hook calls in the > kernel, leaving the existing base logic alone, and demonstrate the > value of the new hooks through example modules, and then subsequently > lobby for migrating the base logic into the hook functions. And what does that gain? It doesn't help selinux, which proports to policy generality. It doesn't help a CAPP (formerly C2) effort, which would have to add hooks anyway for audit purposes. It doesn't help the "no policy" folks. > 2) The work factor for changing _all_ of the existing locations > where the base logic exists is quite substantial, does not directly > contribute to supporting _any_ of our security modules, and > could prevent us from making timely progress in this effort. This isn't a prototype. It's the real McCoy, and it's going to be hard. My CAPP module needs it. It will speed my work considerably if I can do it all in the module. > 3) The potential for introducing subtle bugs by trying to migrate > all of the existing logic behind the hook interfaces seems high. Yup. That's true of any large project. This is a large project. > This is especially true since the right location for inserting > our hook calls often does not correspond with the locations of > existing logic, and our hook calls often need more information > than existing logic (e.g. the capable logic is merely based on > process state, and the capable calls often occur immediately on > entry to a system call, before kernel copies are made of > parameters that are needed by the hook). An example of this > can be seen in the existing changes to the delete_module call, > where the hook call doesn't cover all of the same cases as > the original capable() check. To quote Super Chicken, "You knew the job was dangerous when you took it, Fred." Reverse architecting security policy enforcement into a system is hard, and it has always been so. I've done it twice, and while I agree with your assessment of the difficulty, I do not agree with your conclusions. No appologies. No politically motivated designs. No shortcuts. That's how you get the job done. All other approaches lead to failure and madness. -- Casey Schaufler Manager, Trust Technology, SGI caseyat_private voice: 650.933.1634 casey_pat_private Pager: 888.220.0607 _______________________________________________ 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 Jun 04 2001 - 09:29:42 PDT