TOMOYO Linux - 5 tips to streamline your experience

I've already blogged about TOMOYO Linux, a nice MAC implementation before. This time I'd like to share a few tips that I worked out using TOMOYO. Most (or all) of them may be apparent for long-time TOMOYO users, but hopefully will be helpful for newcomers.
These tips are based on the tomoyo-tools v2.x (for mainlined version, i.e. included in the vanilla kernel and using LSM).  Use ccs-patternize, ccs-loadpolicy etc. for 1.x series.

1. Use initialize_domain
   Tomoyo creates separate domains for all execution paths. If you execute, say, Firefox web browser from a bash shell running in gnome-terminal, then from gnome menu and finally from gnome “run” dialog, you’ll end up with three distinct domains (and the number is possibly infinite, since you can start any application in many ways). Since you probably want to use same policy rules for all Firefox domains, no matter how Firefox was started, use initialize_domain rule in the exception policy, e.g.
   
   
   initialize_domain /usr/bin/firefox
   This way only one domain, “/usr/bin/firefox” will be created in the system.
   
2. Use keep_domain
   Many applications spawn child processes and execute helper programs - for instance, /usr/bin/firefox is just a shell script, that runs /usr/lib/firefox-x.y.z/mozilla-run.sh, which in turn starts firefox-bin; the latter runs plugin-container and so on. Since you’re probably interested in confining an application as a whole, you may consider keeping all child processes in the same domain as the parent. Put
   
   keep_domain /usr/bin/firefox"
   
   in the exception policy and all execution paths created by /usr/bin/firefox domain will use same policy rules. Be aware however, that this loosens security and violates the rule of minimum privileges a bit. For example, plugin-container is responsible for running macromedia flash content plugin (among other plugins) and running it in the same domain as /usr/bin/firefox means it gets all the privileges granted to Firefox itself.
   
   
3. Use tomoyo-patternize combo
   You probably already know and use tomoyo-patternize, but the trick is to pipe it with tomoyo-savepolicy and tomoyo-loadpolicy combo for fast and efficient policy updates and tweaking. The “-” parameter of tomoyo-savepolicy / tomoyo-loadpolicy dumps policy rules to  standard output or reads rules from standard input respectively. Chain it with tomoyo-patternize like this:
   
   tomoyo-savepolicy -d | tomoyo-patternize ‘pattern1’ ‘pattern2’ … | tomoyo-loadpolicy -df
   
   And you can apply patterns immediately. This combo is so useful, that you may consider putting it in a wrapper script, e.g:
   
   #!/bin/sh
   tomoyo-savepolicy -d | tomoyo-patternize $@ | tomoyo-loadpolicy -df
   
   Don’t forget that changes are made to the policy rules currently loaded in the kernel (no changes are made to the /etc/tomoyo/domain_policy.conf file), so don’t forget to execute tomoyo-savepolicy before shutdown....
   
   
4. Use recursive dir matching
   The recursive directory matching operator /\{dir\}/ matches one or more repetitions of 'dir/'. Use it with “\*” as a directory argument to match all subdirectories (and their subdirectories etc.) of given directory, regardless of depth. This is useful if you don’t know directory structure in advance or don’t need to grant specific permissions for subdirectories. For instance, Firefox extensions tend to mess a lot with their files in ~/.mozilla/firefox/\*/extensions directory and it subdirectories, so you may want to grant read, write, create, truncate, link, unlink rights to ~/.mozilla/firefox/\*/extensions/\* (for files/dirs in extensions directory) and ~/.mozilla/firefox/\*/extensions/\{\*\}/\* (for files in subdirectories of extensions directory, arbitrary depth).
   
   
5. Use path_group for common paths
   There is a lot of common paths that applications are accessing, for instance all GUI apps will read font files and fontconfig related files, all GNOME apps will read GTK configuration files, icons, themes etc. Create path_group definitions for common stuff, e.g.
   path_group FONTS /etc/fonts/\*
   path_group FONTS /etc/fonts/\{\*\}/\*
   path_group FONTS /var/cache/fontconfig/\*
   path_group FONTS /home/\*/.fontconfig/\*
   path_group FONTS /etc/fontconfig/\{\*\}/\*
   path_group FONTS /usr/share/fonts/\{\*\}/\*
   path_group FONTS /usr/share/fonts/\*
   path_group FONTS /usr/share/fonts/\{\*\}/\*
   
   And then simplify your domain policy rules like this:
   allow_read @FONTS
   
   Do this for other common files, e.g. ICONS, THEMES, ALSACONF, SOUNDDEV etc.