Quoting David A. Wheeler (dwheeler@private): > Stephen Smalley asked: > > Do you really want to encourage proliferation of ad-hoc special purpose > > LSMs? > > Yes, I think it's a good idea, but perhaps > my mental model of "typical stacking use" is very > different from yours. > > I expect that most people will choose at most one > large, general-purpose access control model like SELinux, which > defines a broad access control model covering all > circumstances. And I expect there will be very few such > general-purpose models; "traditional Unix" and "SELinux" > seem to be the two most popular right now in LinuxLand. > > But then there are various activities that can create > a vulnerability, or help lead to such a state, that you want > to prevent, yet aren't easily covered by a traditional model. > For example: > * Limit filenname creation to certain formats (e.g., forbid > leading "-", forbid control characters, require UTF-8 format), > because some filenames can be easily abused to cause vulnerabilities. > * Forbid following tempfiles/symlinks in certain combinations, > like OpenWall does, because they can lead to race conditions > * Detect sequences that appear to be, in combination, an attack & > prevent them. E.G., an Intrusion Prevention System. I for one am very curious and eager to see (and do) more research about meaningful assurance of security solutions - and by meaningful I might mean either usable by an end-user (end-user probably means policy/lsm writer), or able to actually show something meaningful with some level of assurance. For instance, correctness of LSM itself was studied (http://mail.wirex.com/pipermail/linux-security-module/2002-January/2557.html plus usenix and ccs papers), as was the integrity of the TCB under the selinux example policy (http://www.usenix.org/events/sec03/tech/jaeger.html). These two show that it is possible to reason about both code and policy. Verifying policy using automated tools may be easier to do given the clear semantics of policy. Years ago I had some pretty simple perk/tk based programs for analyzing DTE policy, and Tresys has good tools for selinux policy. On the other hand, there will always have to be at-a-glance verification, and I have no idea whether this is easier for one or the other, given an equivalent amount of experience. And tools like cqual, which I must admit I haven't tried to use yet, may facilitate code analysis as well as existing tools facilitate policy analysis. thanks, -serge
This archive was generated by hypermail 2.1.3 : Thu Jun 30 2005 - 15:37:35 PDT