Allow rootless containers to use AppArmor profiles

[kernelmethod]

Previously, Podman would print an error if you tried to run a container
with an AppArmor profile as a non-root user, e.g.

$ podman run --security-opt apparmor=my-profile ...
Error: Apparmor profile "my-profile" specified, but Apparmor is not
enabled on this system

In fact, the only thing that Podman needs root privileges for is reading
/sys/kernel/security/apparmor/profiles to see if the profile is already
loaded, which isn't strictly necessary.

This commit removes the 'IsLoaded()' check that occurs when you try to
specify an AppArmor profile as a non-root user, as well as the other
checks in pkg/apparmor/ for whether the program is running as UID 0. The
check for whether the AppArmor profile is loaded should now be deferred
to the container runtime at the point where it writes to either
/proc/self/attr/exec or /proc/self/attr/apparmor/exec, since the write
should fail if the profile is not loaded.

Closes #958.

[kernelmethod]

Built with these changes to common, Podman is able to use a custom AppArmor profile when you run a rootless container:

$ kernelmethod@debdev:~/podman/podman$ podman run -t --security-opt apparmor=my-profile alpine:3.15 ls /tmp
ls: can't open '/tmp': Permission denied

The check for whether the profile exists gets deferred to the container runtime when it tries to write to /proc/self/attr{,/apparmor}/exec. This is probably how things should be, since there isn't (to my knowledge) a way to check the existence of an AppArmor profile as a non-root user that doesn't involve writing to procfs.

The downside of all this is that you get a somewhat opaque error if you try to run a container with a nonexistent profile:

$ podman run -t --security-opt apparmor=foobarbaz alpine:3.15 ls /tmp
Error: runc: runc create failed: unable to start container process: error during container init: unable to apply apparmor profile: apparmor failed to apply profile: write /proc/self/attr/apparmor/exec: no such file or directory: OCI runtime attempted to invoke a command that was not found

But that's an issue for runc, and to be fair, the old error was even less helpful:

$ podman run -t --security-opt apparmor=my-profile alpine:3.15 ls /tmp
Error: Apparmor profile "my-profile" specified, but Apparmor is not enabled on this system

(Which is inaccurate since AppArmor is in fact enabled on my system.)

[rhatdan]

LGTM
@saschagrunert @vrothberg PTAL

[saschagrunert]

LGTM

[vrothberg]

LGTM, thanks!
@giuseppe, can you give a final head nod?

[giuseppe]

LGTM

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: giuseppe, kernelmethod, saschagrunert

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [giuseppe]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[giuseppe]

/lgtm

[rhatdan]

Could we revisit this? I can not see what was blowing up in Podman CI/CD system any longer. Could it just have been an ancient version of ubuntu that was blowing up?

[kernelmethod]

Could we revisit this? I can not see what was blowing up in Podman CI/CD system any longer. Could it just have been an ancient version of ubuntu that was blowing up?

From what I remember (and from #969 (comment)), the issue was that Podman opens /sys/kernel/security/apparmor/profiles to check whether the default Podman AppArmor profile has already been loaded into the kernel (which requires root privileges). If that check fails, then Podman generates the profile and loads it with apparmor_parser.

The changes in this PR modified the apparmor.IsEnabled() so that it doesn't automatically generate an error if run as a non-root user. That it turn caused Podman to proceed to the check on /sys/kernel/security/apparmor/profiles in its rootless tests, which failed in the CI/CD pipeline.

[rhatdan]

Can we fix this Patch to not do that or add a new API to check if the apparmor is loaded?

[kernelmethod]

Can we fix this Patch to not do that...

Well, I suppose. I think the way to do that would be to only attempt to load the default profile into the kernel if we're running with uid 0, and just skip the check and loading altogether otherwise. For that to work without breaking Podman on AppArmor-enabled kernels we'd need to make the default profile unconfined for all non-root users. IMO though it'd be better to solve containers/podman#15874 first by storing the default profile in /etc/apparmor.d/, and then we can skip the whole profile checking and loading process to begin with.

... or add a new API to check if the apparmor is loaded?

The only way to rootlessly check for the existence of a profile is to attempt a profile transition by writing to /proc/$pid/attr/apparmor/{current,exec}. It's a little ham-handed but we could fork, have the child attempt a profile transition, and use the result to determine whether the profile has been loaded. Really, though, the standard way to do this would be to skip the check altogether and just pass along the profile to the container runtime to fail when it attempts to perform a profile transition.

[rhatdan]

Well I am certainly not an expert in this, being the SELinux guy, and most of the core engineers know little of apparmor, so we need community to take the lead. If you could make this work it would be great.