When I gave examples of why I would want a stacker: >>* 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 ... Stephen Smalley replied: > I think that this is approaching the problem the wrong way - ad-hoc > solutions for specific attacks, rather than thinking about the general > problem. For example, malicious symlinks are just a particular instance > of the problem of a high integrity process being corrupted by low > integrity data. If you can develop a general, easily-understood solution that COMPLETELY solves your problem, then that's often the best approach. And I should note that I like & use SELinux. But sometimes the best general, easily-understood solution is to enable composition of different modules. The fully general case can easily become one huge monolith that tries to be all things to all people, and isn't nearly as easily understood as a set of simple modules (each of which are easy to reason about). Let's go back to the first of my examples - I want to have a security policy that limits created filenames to certain formats (for EVERYONE, in ALL filesystems -- even root). Why? There are lots of attacks based on funky filenames (newlines in filenames allow files to divert to other files, control characters in filenames to trigger processing, leading "-" that gets confused with options, non-UTF-8 values that scramble data values & displays, etc.) I suppose I could require that all programs and humans be perfect, but I think I'd better not count on it. How would I do that in SELinux? Yes, SELinux could add that, but since many wouldn't want that, it'd be an odd wart in SELinux. It's easier to conceive of such a security policy as a set of separate modules, stacked in by those who desire it. > If such features are added as ad-hoc solutions to specific attacks,then > yes, the result will be unwieldy, but that will be true whether it is > done by a single LSM or ten of them. If you consider the general issues > and seek a general solution either via configuring SELinux or, if truly > necessary, extending it, then it need not be unwieldy at all. You can > leverage common mechanism toward solving that problem that already > exists to help with other problems. Only where the general solution can be found, and is more appropriate to use than the alternatives. A Turing machine solves any computable access control question, but I have no desire to use one directly :-). All "general" solutions are actually ad-hoc if you view them from the point-of-view of a higher level of abstraction. Specialized countermeasures are sometimes a better approach than trying to do it all in a single monolith, if the countermeasure fully covers an important case and isn't easily thwarted by an attacker. It's often not hard to reason about them, because their focus is sufficiently narrow that they only forbid that which should never happen anyway. This isn't necessarily in conflict with SELinux at all. For example, I want to combine SELinux with stuff that limits filename patterns. I see no conflict there. --- David A. Wheeler
This archive was generated by hypermail 2.1.3 : Thu Jun 30 2005 - 13:57:06 PDT