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. Nobody will agree on exactly what that set should be, but that's perfect for loadable stackable modules... just load the set that describes what YOU want to prevent, given your expected use of the system. Different expected use, different set of modules. > That would seem to lend itself toward: >- fragmentation of already scarce security resources that could instead >be working toward a common unified solution, Quite the reverse, I believe. A single LSM that covers SELinux-like mandatory access controls, illegal filename patterns, handles OpenWall symlinks, detects sequences that are malicious, and so on would be completely unwieldy. Instead, break the problem down. Since many of the modules I envision are more 'detect specific kinds of problems', exactly what you have to detect is very system-dependent. >- most LSMs remaining out of tree, I doubt it; people will want them reviewed, which will push them into the tree. >- no real review of how these LSMs compose (or should not compose) by >people who might be capable of evaluating them (most sysadmins won't be >able to perform such analysis on their own), Composition in the _general_ case is extremely hard. But composition in the special case is often much easier. In particular, if you only forbid activities that should never be allowed to occur, there's no loss. The risk is that by forbidding to allow some activity, you create a vulnerability. E.G., sendmail couldn't drop privilege in one model, and thus ran vulnerability when it shouldn't have. This is a real risk, but it's also a risk to allow other dangerous activity, so trades & thought are necessary. >- no stable kernel security model or API due to variances in the set of >LSMs present in any given kernel and thus no effective leveraging of any >specific security model or API by upstream applications that want to be >portable. I don't think this dire circumstance needs to occur. --- David A. Wheeler
This archive was generated by hypermail 2.1.3 : Thu Jun 30 2005 - 08:48:49 PDT