If you are looking to demonstrate the generality of the LSM interface or the Flask architecture, then I think SLIM is worth considering precisely because it implements one of the few protection strategies not already implemented by SELinux. sds> i.e. lack of support for enforcing least privilege, reliance on sds> trusted subjects, lack of support for assured pipelines. I'm not one of the SLIM developers, but here's my $0.02US based on what I've read about it and my past work on LOMAC: It is correct to say Low Water-Mark schemes like SLIM don't provide the kind of least-privilege confinement you can get from something like SELinux. This is because SLIM's protection strategy is not an SELinux-style least-privilege strategy---and if it was, I think it wouldn't be interesting because SELinux already implements this strategy quite well. SLIM and SELinux implement different strategies. They both provide useful protection in different ways. In fact, each has its own interesting functionality that you can't get from the other: The SELinux strategy is to confine processes to their least required privilege. As Stephen noted, you can use SELinux to implement assured pipelines --- something that is not possible in a system like SLIM. The SLIM strategy, on the other hand, is to track the spread of low-integrity data, much like Perl taint-mode. It has its own tricks that can't be duplicated by systems like SELinux: SLIM watches what privileged processes read, and "demotes" those that read potentially-dangerous low-integrity data. The low-integrity data might contain a Trojan horse capable of gaining control of the process through some application bug. But, since the very act of reading the Trojan causes the process to lose its privileges, the Trojan gains little. This demotion functionality is particularly useful when administrators run programs on the command line, some to touch high-integrity parts of the system, some low. Demotion puts the low programs in their place automatically. Presently, Flask/SELinux doesn't "demote" processes. As Stephen suggested earlier, if you wanted to adopt a more SLIM-like strategy in SELinux you could conceivably write a policy with Biba Strict-style high- and low-integrity contexts. But in order to prevent privileged high-integrity processes from reading Trojan horses, your policy would have to prevent them from reading low-integrity data entirely. This means that, when acting as a privileged administrator, you wouldn't be able to "see" low-integrity things like the contents of user home directories. Although this is safe, it's quite different from traditional UNIX. SLIM's use of demotion allows administrators to "see" the entire system and to operate in a more traditional fashion. - Tim Fraser
This archive was generated by hypermail 2.1.3 : Mon Nov 28 2005 - 18:34:04 PST