--- "David A. Wheeler" <dwheeler@private> wrote: > 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. There really isn't much point in introducing a general scheme and then restricting its use. I very much like the idea of lots of security models being introduced. > 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. I agree with this. The fact that the dock will handle an aircraft carrier does not preclude its use by a scooner, however. Okay, so there are a couple popular "big" models. They don't appeal to everyone. > 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. LSM is a good framework for modest added policy restrictions. Why on earth would anyone want to discourage its use? > > That would seem to lend itself toward: > >- fragmentation of already scarce security > resources that could instead > >be working toward a common unified solution, To quote a colleague, "Not everyone wants SELinux". Stephen and I are well known to not share a common vision. That doesn't mean that I think what he's doing is bad because it sucks away resources from the One True Security Scheme. > 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. Just as a single file system implementation that speaks NFS, SMB, ext2, ext3, xfs, and jfs would be. > 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, That's hardly surprising given that the first response to a proposed introduction is always "Well, you can do that with SELinux, so it shouldn't go in". > >- 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. Again, composition of unrelated modules is hard. In SELinux the composition of policy appears somewhat difficult, too. > 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. I don'y buy Stephen's argument at all. Security is to important to try to put the brakes on. No, we should not try to unify on a single model. Even if that model claims to do everything up to and including cleaning the bathrooms. The truth is that security needs change and today's hit solution (SELinux) will go the way of yesterday's (Trusted Solaris/Irix/HPUX) and the ones before that. I would hate to see Linux become yet another fossil in the slate beds of system security because it overcommitted to a particular security fad. Casey Schaufler casey@schaufler-ca.com __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail
This archive was generated by hypermail 2.1.3 : Thu Jun 30 2005 - 12:48:04 PDT