[apparmor] RFC: draft proposal for enabling AppArmor by default in Debian

[Simon McVittie]

On Thu, 03 Aug 2017 at 17:20:20 -0400, intrigeri wrote:
> Hi Debian AppArmor team, upstream AppArmor people, people who
> volunteered to review this text, a few maintainers of packages that
> include AppArmor policy, and some innocent bystanders!

You have presented the case for enabling AppArmor well, so here is the
devil's-advocate position: issues with doing so.

> AppArmor confines programs according to a set of rules that specify
> what operations a given program can access, e.g. it can prevent your
> PDF reader and video player from accessing your GnuPG secrets keys and
> executing arbitrary code. This proactive approach helps protect the
> system against both known and unknown vulnerabilities.

Does it, though? To judge the value of AppArmor, I don't think it's
enough to know how many wrong denials we have (functionality being
broken by AppArmor): we should also understand how many attacks would
have been mitigated or prevented by it.

If the AppArmor rules are strict enough that it really does prevent or
at least mitigate attacks, then we can tolerate a certain amount of
breakage or annoyance.  If they are not, then AppArmor adds literally
no value, so any cost at all seems unacceptable.

(I suspect the real answer is somewhere in between: some attacks are
mitigated or prevented but others are not.)

In general, a defender needs to block every route to arbitrary code
execution (or whatever we are trying to prevent), whereas an attacker
only needs to succeed once. For example, if you can get access to X11,
you can inject input, take screenshots and even implement a keylogger;
the accessibility bus is both poorly-understood and alarmingly powerful;
and if you can write to ~/.config or ~/.local/share, you can almost
certainly configure something unconfined (gnome-settings-daemon?) to
execute arbitrary code on your behalf.

> * in a few other Debian derivatives (Whonix, Subgraph OS) for at
>   least a couple years; I suspect that Simon McVittie can add to
>   the list.

Until recently I was involved in Apertis, an automotive/embedded Debian
derivative, which uses AppArmor to provide a security boundary between
platform components (for which it is well suited) and also to provide
a security boundary between user-installable, Android-style "apps"
(for which I have grown less convinced that it is the best answer,
and have recently been looking at Flatpak).

Apertis tries to use AppArmor in a much more strict way than would be
expected on the desktop. Unfortunately, we found that some of the
policies we wanted to express were difficult to phrase in terms of
AppArmor rules (sorry, I don't immediately remember any concrete
examples). We ended up writing either overly broad or overly narrow
rules.

I have come to believe that sandboxing unmodified application code that
was not designed to be sandboxed is to at least some extent a doomed
endeavour. Flatpak's trick to dodge this is that its maintainers are
willing to modify libraries like GLib (and able to get patches
accepted) and make those libraries available in their "runtimes" for
sandboxed apps, so that anything making use of the library's high-level
APIs automatically becomes more sandbox-friendly over time.

> A number of maintainers accepted shipping AppArmor policy in their own
> package. If you're one of them, please consider providing feedback
> about how it went for you.

I am one of these. I maintain the Quake series of game engines in
Debian, which have AppArmor profiles (currently in complain mode).
I also maintain game-data-packager, which can create packages for some
proprietary binary-only games such as Unreal and Unreal Tournament;
those also have AppArmor profiles (again currently in complain mode).

My experience has been that updates to lower-level libraries like SDL
and udev frequently cause me to have to update my profiles, even without
code changes to what I actually maintain. If they were in enforcing
mode, functionality would presumably have been lost.

Games are pretty much the perfect example of something that should
have AppArmor profiles - their legitimate interactions with user files
are minimal, and I like to characterise them (not entirely jokingly)
as basically a series of security flaws joined together by a physics
engine. So if we can't confine those reliably, that's a concerning
data point.

> In the last few years, a number of tools appeared that use Linux
> namespaces to achieve similar goals as AppArmor and SELinux. To name
> a few of those that support desktop applications: bubblewrap (used by
> Flatpak), Subgraph OS' oz, Firejail, Subuser and Ubuntu Snappy.
> And our default init system has very interesting functionality that
> does similar things for system services.

My understanding is that Snappy sandboxing relies on AppArmor, not
namespaces.

>  * Very interesting long-term perspectives in terms of user
>    experience. E.g. the concept of "portals" embraced by Flatpak and
>    Ubuntu Snappy will improve security *and* user experience at the
>    same time.

I would go as far as to say that sandboxing without something similar
to portals is unlikely to succeed - either it will be overly narrow and
break desired functionality, or it will be overly broad and fail to
close all the opportunities for an attack to succeed.

>  * Not very mature: I've evaluated these tools for Tails and deemed
>    them not ready for prime-time (either breaks basic functionality
>    such as universal access technologies, or the security part is
>    planned but not implemented yet).

In the case of universal access technologies, we briefly looked at the
AT-SPI accessibility bus during a GTK/Flatpak hackfest, and came to the
conclusion that it is terrifying - it's an ideal place to put a keylogger,
or take control of windows outside the sandbox. That's why Flatpak does
not give access to that bus. If we are going to have a11y that works for
sandboxed apps and does not fundamentally undermine security, it will
have to be designed for the purpose by someone who understands both the
security model and the needs of a11y. At a minimum, it would need a
concept of more- and less-privileged peers on the bus, which it
currently lacks.

(AppArmor D-Bus mediation would help here, but that isn't in
upstream or Debian kernels.)

>  * Insufficient: the aforementioned tools either already rely on
>    a LSM, or soon will, to provide adequate protection.

I am not aware of any plans for Flatpak to rely on an LSM: it's all
done with namespaces, seccomp and NO_NEW_PRIVS. Flatpak is entirely
unprivileged, and bubblewrap doesn't retain CAP_MAC_ADMIN (it's setuid
on Debian and RHEL, but is designed to be unnecessary to make setuid on
distributions like Fedora and Ubuntu that allow unprivileged userns
creation).

> In any case, it is my understanding that this is not an either/or
> situation: one can perfectly well use this tools with
> AppArmor enabled.

Mount namespaces interact poorly with a path-based LSM like AppArmor.
With the way in which Bubblewrap currently uses pivot_root() in its
private mount namespace, a Flatpak app will currently appear to
AppArmor to be accessing filenames like /newroot/app/bin/openarena,
/newroot/usr/lib/libGL.so.1 and /newroot/home/smcv/, and it does not
appear to be possible to disambiguate which root we are operating in.

(I would love to be proved wrong on this!)

Regards,
    S