what would it be like if we just used xfs and implemented SGI's ACL's. Just brainstorming alternative to SE. Michael Stephen Smalley wrote: >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. > > >
This archive was generated by hypermail 2.1.3 : Wed Oct 27 2004 - 14:19:23 PDT