Defense in Depth - AppArmor

[apyrgio]

Parent issue: #221

If an attacker manages to escape the container, we want to restrict them as much as possible. One way to do so is by using AppArmor, which is also mentioned in the CIS Docker advisories (official link, mirror).

Docker already uses an AppArmor profile when running containers (https://docs.docker.com/engine/security/apparmor/). We should see if this profile covers our needs, and if it is enforced on Docker Desktop.

[apyrgio]

Linux

Since we don't control the Linux host, there are not many things that we can do. If the host supports AppArmor (typically Ubuntu), then Docker will use the default AppArmor profile.

[apyrgio]

Windows

There are two ways that a user can install Docker Desktop in Windows; either via WSL2 (recommended) or Hyper-V. We'll focus on WSL2, which is both supported in most Windows flavors, and is recommended by Microsoft.

It seems AppArmor is not available in WSL2 by default: microsoft/WSL#8709. Attempts to set an AppArmor profile via --security-opt apparmor=<profile> fail silently as well.

[kernelmethod]

Hey -- I'd be interested in helping with this issue (if external help would be appreciated)!

My understanding (please correct me if I'm wrong) is that under the hood, Dangerzone is using Podman rather than Docker, including on Debian/Ubuntu. Right now, AppArmor support is broken on rootless Podman containers -- see containers/podman#15874. Once that issue has been resolved, it should be possible to use an AppArmor profile to further constrain the containers that Dangerzone runs in.

Docker already uses an AppArmor profile when running containers (https://docs.docker.com/engine/security/apparmor/). We should see if this profile covers our needs...

Linux

Since we don't control the Linux host, there are not many things that we can do. If the host supports AppArmor (typically Ubuntu), then Docker will use the default AppArmor profile.

The default AppArmor profiles provided by Docker and Podman are both extremely liberal (and Podman currently doesn't even apply this profile anyways), and they aren't going to meaningfully prevent or mitigate remote code execution. For the most part, these profiles just exist to prevent access to some exceptionally dangerous interfaces to the kernel, but you can get a lot more mileage out of a more specific profile.

[deeplow]

Hey -- I'd be interested in helping with this issue (if external help would be appreciated)!

Thank you for your interest and for finding that out about the current (unfortunately) situation about rootless containers. Right now for this feature we're more in an exploratory phase to understand how much Dangerzone can benefit from it (insights like what what you just shared above).

If you take a look at the parent issue (security in depth), we're also considering other methods to harden Dangerzone. From my understanding in fedora-based systems apparmor isn't present. Instead, they have SELinux, which adds and extra component to manage, should we go this strategy. However, managing custom SELinux policies is pretty advanced and probably unmanageable for a small project like this, it seems.

The above is just to say that we are looking to understand best how to more forward holistically from a security in-depth perspective, on what will increase most the security for everyone using Dangerzone. Seccomp is looking like a promising avenue as all hosts would benefit from it.

But with that said, I think that if you know more about AppArmor, some other challenges that we're not yet considering and how to get around some of the limitations raised in the above discussions, that would be appreciated.

Thank you!

[kernelmethod]

Thanks for the clarification!

From my understanding in fedora-based systems apparmor isn't present. Instead, they have SELinux, which adds and extra component to manage, should we go this strategy. However, managing custom SELinux policies is pretty advanced and probably unmanageable for a small project like this, it seems.

Indeed -- I'm not an SELinux expert by any means, but my limited experience with it has not been great. Managing SELinux policies can be quite challenging (and that's certainly the reputation that SELinux has).

The above is just to say that we are looking to understand best how to more forward holistically from a security in-depth perspective, on what will increase most the security for everyone using Dangerzone. #225 is looking like a promising avenue as all hosts would benefit from it.

Yes, that's a completely fair consideration. While seccomp is a great mechanism and should absolutely be implemented if possible, I'll mention that it's fairly coarse-grained in ways that AppArmor is very good at covering. For instance, as soon as you allow openat you open the door for a process to read or write any arbitrary file, whereas AppArmor strictly allow-lists the files that can be read/written/executed.

Seccomp profiles also apply at a container level, rather than a process level. Since DangerZone uses a fairly complex suite of software I would imagine that this would require some fairly liberal seccomp profiles, which must subsequently be applied to all processes in the same container. By contrast, AppArmor profiles apply at a process level, and you can define different permissions for each program that runs in DangerZone's containers.

But with that said, I think that if you know more about AppArmor, some other challenges that we're not yet considering and how to get around some of the limitations raised in the above discussions, that would be appreciated.

I think that by far the biggest short-term challenge will be the aforementioned issue containers/podman#15874. Unfortunately the only immediate workarounds I can think of would be to drop Podman altogether and run Docker rootlessly, or to skip Podman and just execute the container directly using runc / crun (to which Podman acts as a frontend).

One other thing that's worth considering -- I saw that in #225 (comment), you mention that it's difficult to detect when a seccomp policy violation occurs. With AppArmor (and I believe SELinux), doing this detection is a lot easier -- policy violations automatically get written to the kernel ring buffer. For example (with a restrictive test profile called foo):

kernelmethod@debdev:~$ aa-exec -p foo -- cat /etc/passwd
cat: /etc/passwd: Permission denied

kernelmethod@debdev:~$ sudo dmesg | grep 'apparmor="DENIED"'
[ 1757.710390] audit: type=1400 audit(1689495068.794:26): apparmor="DENIED" operation="open" profile="foo" name="/etc/passwd" pid=1392 comm="cat" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

[deeplow]

Thanks for summing it up so well. I have quoted your whole comment on #221 so that we keep this discussion focused on AppArmor.

I think that by far the biggest short-term challenge will be the aforementioned issue containers/podman#15874.

Yes, that will definitely be a blocker. And thanks for starting that issue, in the first place! The fact that it remains unfixed seems odd because we're talking about security feature and one of the base goals of podman (as I understand it) is the ability to run run rootless containers. Users on aa-enabled systems may wrongly assumed they have an extra layer of security. A warning about this fact should at least be implemented.

Other than that, I think by far the biggest issue with AppArmor is that it's not available on docker desktop nor podman on windows (as mentioned above) and possibly macOS as well as any fedora system. This means that an AppArmor profile would only cover a minority of users. Not stating that it's not worth it, but it would be more if we found a non-totally unsupported way of adding apparmor to those platforms.