Support AppArmor profiles?

[hugelgupf]

Twitter conversation context:

I understand. I'm looking at protecting the container from external attacks, not container escapes (I can use gVisor to protect against this). I can do this on Ubuntu by running by Docker with --security-opt apparmor=<my_custom_profile> Will gVisor support this? -- @securityfoo

Supporting AppArmor profiles doesn't actually seem that hard:

• runc does it at this step in the process: https://github.com/opencontainers/runc/blob/69663f0bd4b60df09991c08812a60108003fa340/libcontainer/standard_init_linux.go#L95
• applying an apparmor profile is just writing the name of the profile you want applied to a proc file: https://github.com/opencontainers/runc/blob/69663f0bd4b60df09991c08812a60108003fa340/libcontainer/apparmor/apparmor.go#L48
• not 100% sure how the name gets to runc (where in the OCI spec?) but you could easily do some code archaeology from one of these two links.

I don't know if this is something we want to support, but I'm going to leave all the bits here and let someone else decide.

[hugelgupf]

To be completely clear, this would be a profile applied to the sandbox, not to the application inside the sandbox.

[hugelgupf]

Which leaves open the question of -- when you specify an AppArmor profile to docker on the cmdline, do you expect that to be applied to the container/sandbox <-> process boundary or the container/sandbox <-> kernel boundary? I don't know if the spec even considers that or specifies it.

[iangudger]

What do you mean by external attacks? Protecting the sandbox from other processes on the host? Hardening the sandboxed app?

[fvoznika]

I think there are a few separate questions here:

1. Can I use AppArmor to protect the container from external attacks?
   AppArmor is not meant for that. Instead, it limits what the container is allowed to access, similar to SELinux and seccomp-bpf. There are other technologies better suited to protect the container from external attacks.

2. Should I use AppArmor inside gVisor?
   One of the main advantages of gVisor is that it isolates the container from the host without needing complex filters and policies. Thus, using AppArmor would be redundant and is not necessary.

3. Should I use AppArmor outside of gVisor?
   The sandbox process runs as a low privileged user, inside isolated namespaces. This is more restrictive than common profiles. In addition, AppArmor profile should apply only to a single container, while gVisor sandbox runs multiple containers that can have conflicting configuration.

[hugelgupf]

One of the main advantages of gVisor is that it isolates the container from the host without needing complex filters and policies. Thus, using AppArmor would be redundant and is not necessary.

Right, that much we discussed on twitter, and obviously it doesn't make sense for gVisor to apply an AppArmor profile inside the sandbox. I'm asking the question from comment 2 from an API perspective.

When a user specifies --security-opt apparmor=foo, what do they expect? They probably expect that applications that don't fit the profile (make unallowed syscalls, etc) get killed (or whatever policy AppArmor applies). If you apply the profile to runsc rather than the application in the sandbox, that'd be unexpected behavior for some users.

So even if it was easy to support enforcing an AppArmor profile on the sandbox, I think it may lead to unexpected behavior and we should rather keep not supporting it and let it lead to an error message to explicitly say we don't support this use case.