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

Fri Aug 4 14:02:11 UTC 2017

On Fri, 2017-08-04 at 13:07 +0100, Simon McVittie wrote:
> On Thu, 03 Aug 2017 at 17:20:20 -0400, intrigeri wrote:
> > 
> 
...

> 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 the case of X, you are completely correct. However, I've always taken the
stance that confining X applications with AppArmor has benefit against scripted
or non-targeted attacks and raises the bar for X applications as a step for
better security-designed environments such as wayland-based desktops. Most
packages that ship AppArmor profiles in Ubuntu are not X applications, but
server applications that don't require the use of something as flawed as X (in
terms of security), and therefore the protections are even more meaningful.

> > * 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).

While off topic for this thread (but because you are implying a comparison later
and talking about flatpak extensively (which doesn't use apparmor, but snappy
does)), in your investigation, if you haven't already, I would encourage you to
look at snappy. We can take this off list if you have questions.

Please note my comments regarding snappy are with my snappy upstream hat on, not
my AppArmor upstream hat on.

> 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.

This is particularly true for user-facing applications. Eg, a user wants to
attach a file to an email in a confined email client. AppArmor alone can't solve
this without burdening the user ("put all your attachments into this folder that
you have read access to") and you need out of process trusted helpers that the
client libraries of the apps use. This is something we did for Ubuntu Touch and
flatpak later borrowed in their Portals work. Snappy is now working on enabling
Portals in snappy.

...

> > 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.

Snappy uses a combination of technologies: apparmor, seccomp, device cgroup,
devpts new instance and mount 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.

For *desktop* applications. Server applications can meaningfully be profiled
with just apparmor today. As portals, wayland, etc become more mature and
widespread, apparmor profiles could very meaningfully protect a desktop
application. AppArmor already has a wayland abstraction, it could easily have a
portals abstraction, at which point it is easy to imagine a meaningfully (by
anyone's definition) restrictive profile for a desktop application using these.
These technologies are maturing fast and possibly in time for Buster there might
be some applications that can be profiled without X, with wayland and with
portals. Time will tell-- I'm looking forward to it! :)

> >  * 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.)

Do note, DBus mediation is being pushed to the upstream kernel, but I suspect in
this case that it would not be sufficient as in my experience technologies not
designed for security typically don't have DBus APIs that are conducive to
application isolation via fine-grained DBus mediation. When the service has a
nice API, fine-grained DBus mediation can be really useful (we did this a lot
with new services on Ubuntu Touch, for example), but when it doesn't, DBus
mediation is primarily useful for coarse-grained connection to the service or
not.

> >  * 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).

Actually, adding SELinux support was on the flatpak roadmap, at least at one
point. I think integeri's comment was directed at the open question in the
larger security community of whether containers (system or user) are
sufficiently strong to be used alone as a sandboxing technology for arbitrary
untrusted binaries. People land on different sides, and I'm not trying to hash
that out here. :)

> > 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!)

Actually, with sufficient invocations of pivot_root, you don't need to specify
'/newroot' and simply have rules for '/app/bin/...', '/usr/lib/...' and
'/home/...' (unlike chroot). We do this in snappy today for example. Using those
techniques, you are right you can't disambiguate /newroot1 vs /newroot2 in
policy, but if that is important, you can code the sandboxing application for
that in mind.

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20170804/abca4a2f/attachment.pgp>