Sorry for late response. Daniel Thau wrote: > I have two questions: > > (1) Is there anything I'm missing which would make this a bad idea? I > suspect so, otherwise it'd likely be mentioned somewhere in the > documentation, but I've been unable to think of anything else. I thought it > best to ask on this mailing list before I try to use it.
There are two approaches for restricting accesses. One is controlled from the point of view of subjects (or processes). The other is controlled from the point of view of objects (or inodes or files). The former implementation are TOMOYO and AppArmor, the latter implementation are SELinux and SMACK. However, if some subject is not in the enforcing mode, neither can protect objects you want to protect. Regarding this point, there will be no difference between the former and the latter. Somehow applying the enforcing mode to all subjects is essential for using blacklisting restriction as with using whitelisting restriction when you want to protect objects. But, when you want to protect objects (strictly speaking, when you want to control which object can be read/written/executed by which subject), restricting access from the point of view of objects saves a lot of efforts because read/write/execute is applied to inodes. So, SELinux and SMACK will do it better. If you want to use TOMOYO or AppArmor for doing it, you need to restrict pathname changes (e.g. rename operation, mount operation) in addition to restricting read/write/execute operation. > (2) Is there a better way to go about doing this other than what I have > mentioned? Listing everything under "Domain policy syntax" in the acl_group > seems a bit awkward, and I'm likely to miss something as I'm not completely > familiar with all of the things which TOMOYO can allow/disallow. In November 2007, I tried to use TOMOYO only for forbidding changing wallpaper for desktop session. The approach I used was same as what you described except that I suppressed domain transition using 'keep_domain' directive since 'acl_group' directive was not available at that time. Regards. _______________________________________________ tomoyo-users-en mailing list [email protected] http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
