Mandatory Access Control
Download Tails 0.23 March 19, 2014

Rationale

Using some kind of Mandatory Access Control, such as GrSecurity, AppArmor or SELinux, would make exploitation of security issues in bundled software harder.

Possible solutions

AppArmor

Used in Ubuntu, part of upstream Linux kernel (>= 2.6.36), supported to a certain degree in Debian Wheezy.

Seems really easy to write and maintain policies, many already exist.

A critical problem with stacked filesystems, such as aufs, must be fixed at upstream level before we can use AppArmor in Tails.

It can be workaround'd with alias rules if https://bugs.launchpad.net/apparmor/+bug/888077 is fixed , or by adding "Kernel based alias support". An AppArmor upstream developer is working on improving alias rules support so that we can workaround this. Once this work is complete:

  • We will be able to (and actually, we'll need to) add an alias rule:

    echo 'alias / -> /lib/live/mount/rootfs/filesystem.squashfs/,' \
>> /etc/apparmor.d/tunables/alias

  • We will need to change the /lib{,32,64}/**/ld{,32,64}-*.so mrix, rule into:

    /lib{32,64}/**/ld{,32,64}-*.so     mrix,
/lib/{[^l],l[^i],li[^v],liv[^e],live[^/]}**/ld{,32,64}-*.so mrix,

    ... to avoid it to overlap due to our added alias.

  • We have to deal with other overlaps, such as audit deny owner /**/* m, (from the Evince profile), that will take away the executable mmap permission from> applications in the /lib/live/ path, if the root user (who owns the file) tries to launch an application:

    • either we use rewrite rules instead of aliases. Rewrite rule is the same as alias except it doesn't result in an overlay of the two rule sets, hence getting rid of the deny and x perm conflicts;
    • or we need a way to define that the alias rules should have priority in the union, thus removing the problems; this requires an update to the AppArmor permission merging logic.

  • Alias rules dramatically increase the profiles compile time (e.g. 1min40 for the Evince one, and 8 seconds with the aforementioned rule change). To mitigate that problem, we could:

    • either look at the rules and see if we can't make some tweaks to them;
    • or ship a precompiled policy cached. As long as the parser and kernel are in sync, then policy can be pulled straight from the cache, without an compilation. If the parser detects that the policy is out of date, then the cache will be ignored and compilation will happen.

grsecurity

homepage

grsecurity, along with more kernel hardening features, provides Role-Based Access Control. Some of its bonus features are slowly implemented upstream though (ASLR stack/heap protection, information leakage through the proc and sys filesystems, ways to disable module loading, etc).

A feature that might be problematic is the "admin role" which is a superuser (more then root in grsec) that has the ability to modify/(des)activate grsecurity. How to implement this in a Tails environment, where passwords aren't that secret? Should users of Tails be able to login in that role, and if so, how could we provide a way to do so without lower grsec security by revealing worldwide this password?

Users:

  • Hardened Gentoo offers a grsec-enabled kernel. RBAC policy?

  • Although Liberte Linux uses PaX (Address space modification protection) it does not include grsecurity RBAC feature.

  • Work to add a grsec kernel flavour to Debian seems to be stalled: Debian bug #605090.

  • Ubuntu developers used to actively work to upstream grsec features mainline, but this effort seems to have stalled, or rather moved to another employer along with Kees Cook.

SELinux

Developed initially by big brother (NSA).

It is pretty hard to write and maintain policies, but such policies exist and they can "mostly" be used by different Linux distributions.

Poor support in Debian, improved in Squeeze, does not look like it's going to improve that much.

Smack

The Smack MAC LSM is part of the Linux kernel (homepage, Simplified Mandatory Access Control Kernel). It does not seem to be used by any GNU/Linux distribution out there.

TOMOYO Linux

Some (MAC for files) of the TOMOYO Linux LSM (homepage) was mainlined in 2.6.30; more of it was merged in 2.6.34 and 2.6.36.

It is compiled into Debian Squeeze's kernel.

The out-of-tree patch has far more features, see the comparison of versions for details.

A "tomoyo learning daemon" is actually being developed by a third party : tomld, might be worst having a look and test it.

For informations on the ongoing tests of this solution, see the tomoyo subpage.

RSBAC

RSBAC is a Rule Set Based Access Control. It has a lot of other features. It's just a patch to the linux kernel, and probably won't be integrated upstream. Seems no distributions did integrate it or provide easy ways to do so.

Ubuntu has a package of the rsbac-admin utility.

Resources