On Wed, 2004-10-27 at 14:12, Valdis.Kletnieks@private wrote: > The point is that in this case, *no* domains are trusted - we don't want > end users compiling their Fortran programs to have stuff hijacked out from > under them when they build in /tmp. Similarly, we care about *other* directories > as well - /tmp and /var/tmp are just *two* places things live, there's other > world-writable directories as well. The SELinux policy makes extensive use of derived types for runtime files created by domains, and typically doesn't let domains touch each others' runtime files. So I think much of this protection is already provided, and remember that the directory isn't truly world writable under SELinux unless it is labeled with a type that is world writable (in which case odds are good that we've already defined derived types for the files created in it that are sensibly isolated). > As another example - how would you implement "don't remove other user's files > in a +t directory" in SELinux? Note that nobody seems to think that *that* > semantic isn't sane and desireable - but it's equally hard to state in SELinux, > for the same reasons. Um, no. SELinux provides per-file unlink permission, and as with the previous discussion, you typically don't get to unlink files with types created by other domains. But this discussion is largely irrelevant, I think. I'm not opposing a simple mechanism for stacking of the LSM security fields; I just don't want it to unnecessarily harm the (presently common) single LSM case. I think that is achievable. Just not via a hashtable implementation. And for production, I agree that you ultimately want an integrated security solution. I see stacking as primarily a vehicle for easy experimentation, not for the final system. -- Stephen Smalley <sds@private> National Security Agency
This archive was generated by hypermail 2.1.3 : Wed Oct 27 2004 - 11:24:10 PDT