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

[John Johansen]

On 08/04/2017 05:07 AM, Simon McVittie wrote:
> 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.)
> 
This is true for any security. You can tighten for a specific use
but have to loosen for generic use. Users in particular add a
whole new layer of difficulty partly because the explosion of
potential data files the user might want to access and use cases

A profile isn't going to block many attacks if it approximates
unconfined, but it can if its tuned for a specific use case. Most
profiles lie some where in between, and will mitigate some attacks
and others will get through.

> 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.
> 
yep. This is a generic problem that applies every where. You can
certainly tighten things down. But the more you do it, the more
users or admins turn security off, at which point it doesn't matter
how strict your security is.

Also I will note that the linux desktop really wasn't designed
for applications to be siloed. There are things that can be done
but there is work needed across a lot of different projects.

>> * 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.
> 
yes, this is a well know problem.

> 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.
it does make it more difficult, and will likely almost never result
in a confinement or experience that is as good as when an application
or library has been designed with privilege separation

> 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.
> 
I wouldn't call it a trick, it engineering and work that every security
project can benefit from if its done right. We have certainly tried
to do some of this too.

>> 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.
> 
yes, this will always be an issue with libraries, unless you completely
encapsulate them in your sandbox, like snappy or flatpak are doing.

It can however be at least partly mitigated by better abstractions
that are updated with the library.

> 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.
> 
yes, a means of dynamically extending confinement is a requirement
for tight confinement on anything but the most simple applications.

Delegation in combination with application is how apparmor policy is
supposed to deal with this. Unfortunately delegation is part of the
apparmor model that has not landed yet.

>>  * 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.)
> 
So just to clarify. It is in upstream dbus, however the support for
it is NOT in upstream or debian kernels. The kernel upstreaming is
a wip, we might get it landed for 4.14

>>  * 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.
> 
it is possible, but there are currently issues

> 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!)
> 
This is a real problem currently. We are working on fixing it, but its
not just an apparmor issue. On the apparmor end of things, apparmor
now supports policy namespaces and stacking, allowing for policy
within a container to expect and be fine with a different root. The
delegation and inode labeling support are still a wip and will
provide another avenue for dealing with some of the issues.

However there The kernel currently doesn't make it possible at the
LSM level to properly manage namespaces.

There is a micro-conference at plumbers and bof at LSS this year to
work on the problems of namespacing and the LSM. Hopefully we can
fix these issues soon.