Inconsistent access to unconfined process from the default apparmor profile

[lbernail]

Description

From a container with the default apparmor profile (cri-containerd.apparmor.d in our case, because we are using a CRI setup with a kubelet), I see a different behavior when trying to access an unconfined process on the host (not in a container) and an unconfined process in a container (started with the kubernetes container.apparmor.security.beta.kubernetes.io/<container>=unconfined annotation, which results in no apparmor profile):

• in the first case, I do not have an apparmor error in the kernel logs (but I don't get information either)
• in the second case, I get this error: audit: type=1400 audit(1537817228.528:33270): apparmor="DENIED" operation="ptrace" profile="cri-containerd.apparmor.d" pid=2741 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined"
• in both cases, processes show up as confined with ps auxZ

This error seems to come from this line in the apparmor profile:
https://github.com/containerd/containerd/blob/master/contrib/apparmor/template.go#L73
(ptrace (trace,read) peer={{.Name}}), which controls access to the ptrace syscall and some paths under /proc requiring PTRACE_MODE_READ_FSCREDS such as wchan or environ.

Simply running a ps aux in a container running in host pid namespace with a standard profile will generate this error for all processes running in unconfined containers (which is easy to notice because it is the case for all pause containers).

I'm not sure if this is an issue but the behavior is surprising.
In addition, I was wondering why pause containers were not started with the same default apparmor profile as other containers.

Steps to reproduce the issue:

1. Run a container without an apparmor profile (or if using CRI, simply run a pod, the pause container will be unconfined)
2. Run a container in host pid namepace
3. Run ps aux from the second container and watch for apparmor errors in the kernel logs

Describe the results you received:
Apparmor errors for unconfined process (which makes sense) but only for the ones running in containers.

Describe the results you expected:
Consistent behavior (error for all unconfined processes, or no error if this is caught before apparmor)

Output of containerd --version:

containerd github.com/containerd/containerd v1.1.2 468a545b9edcd5932818eb9de8e72413e616e86e

cc @Random-Liu / @crosbymichael following our discussion on slack

[crosbymichael]

Running in host pid is the reason for this because the container can see all the processes ;)