Tomoyo revisited

Another path-based MAC system like AppArmor; I've probably mentioned in before. It seems to have gotten better in recent versions.

Advantages vs. AppArmor:

- Has a system-wide learning mode a la GrSecurity, which AppArmor lacks.
- Seems to control access to more stuff, e.g. environment variables (as of kernel 3.7.x).
- Almost all the major distros IIRC have support for it; Arch, Debian, and Ubuntu also have the userspace tools.
- You can specify different policies for the same program, under different conditions (e.g. depending on the parent process).

Disadvantages:

- Policy editor is harder to use than AppArmor's tools as of right now, and the interface is a little confusing (especially the keybindings).
- There are some gotchas for newbies in the default behavior. For instance, if you launch Firefox and set its policy to learning mode, per default the generated policy will only apply to Firefox if launched by the same parent process, which is not what most people want!
- Policy rules are a bit less obvious than AppArmor's, and more of a pain to edit (policy editor strangeness again).
- In the absence of manually added rules, globbing seems to be done automatically after a certain number of similar rules are applied. This is probably friendlier for Linux novices, but not so great if you want fine grained control.

My take: Tomoyo is probably a reasonable alternative to AppArmor, and good to have on systems where the latter is not available. Its behavior is actually a little like Geswall or Malware Defender on Windows, with learning mode and all, so people migrating from Windows might find it simpler to use. OTOH it makes fine-grained control a bit more cumbersome than AppArmor; and the behavior of the policy editor (in lieu of a standard text editor) can be a little painful.

Still, it's nice to see the widespread adoption of Tomoyo in distros' stock kernels. At the moment, I believe Slackware is the only major distribution that ships without a MAC system compiled into its kernel; the others all have one or more of Tomoyo, AppArmor, or SELinux.

 

I must admit that I haven't tried Tomoyo. Nevertheless some remarks.

This might be an advantage. However, the question is if this doesn't lead to very complex rule sets (à la Selinux) that make problem debugging a pain.

AppArmor offers that, too, to some extent via Px and Cx which scrub the environment.

You mean for the same helper application? AppArmor offers that, too, via c|Cx.

 

Ah sorry, I didn't know that about AppArmor. Yay me.

Also it seems I was wrong about the automatic globbing. Not entirely sure though. Suffice to say that the Tomoyo policy editor is a great deal less useful to desktop users than aa-genprof and a text editor.

 

hi,

Yes AppArmor is mature, and for my concern more armored to mitigate kernel exploitations than SeLinux or Tomoyo.
regarding Tomoyo, i think that its little brother Akari is more interesting (more easy to implement and configure)
http://akari.sourceforge.jp/about.html.en

Most Linux distributions are hardened by default, and on a desktop environment, it appears useless to monitor every system call, to configure every access to every application....this is just given more food to the insatiable paranoia...

Rgds

 

I have to disagree a bit. Per default most distros run browsers, chat clients, and other internet-facing programs with the same privileges as the user account that launches them; which means that if one of those programs gets compromised, data stored in the user account could be stolen. That could be something minor (recorded forum passwords, etc.) or not so minor (GPG private keys, for instance).

Restrict Firefox with e.g. an AppArmor profile and you can eliminate that possibility (barring kernel exploits). IMO making Firefox unable to read your private key isn't paranoid, it's perfectly sensible.

Edit: OTOH, browsers (and email clients, and other internet-facing programs) tend to routinely access a lot of "personal" data as a matter of day-to-day functionality. Including data stored in the browser's own cache, which you obviously can't hide from it. In a lot of cases, the only sensible way to deal with security is to prevent remote exploits in the first place.

Perhaps the OpenBSD people do have a point.