On Mon, 2005-11-28 at 21:32 -0500, Tim Fraser wrote: > 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. As I noted in my earlier posting, I see such demotion as a problem on several counts: - pervasive non-tranquility in security labels, with the attendant concerns about revoking access to resources already held by the process at the time of the label change, - application misbehavior in the face of automatic demotion, which could be maliciously induced (e.g. supply a low integrity data file as input to a high integrity process, and watch it be surprised when it can read that file but can suddenly no longer proceed with its normal operations for modifying high integrity data, possibly failing in a security-relevant manner), - degeneration of the system toward the lowest integrity level over time. > 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. I'm not clear on the latter claim. If /home is labeled as low integrity per your earlier example, then a non-root user login (at least one with a home directory under /home) will be demoted to low integrity, preventing the "traditional fashion" of logging in as a non-root user and then later using su/sudo/userhelper/... for administrative tasks (you might argue that this is a security feature, but it certainly isn't conducive to traditional operation). Similar issues seem likely with /tmp, /var, etc and contamination of many programs as a result even when run by an admin at high. And we know from our own experience with SELinux that applications and library functions have a habit of probing directories and files even when they don't truly need access to them, so there seems to be a high risk of unnecessary automatic demotion (in comparison, in SELinux, we just deny the access when it isn't actually needed for operation, and dontaudit it to avoid noise in the audit log, so the process proceeds without contamination). -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Tue Nov 29 2005 - 05:26:48 PST