[apparmor] Help debugging a confusing Full System Policy error

[John Johansen]

On 3/1/23 11:55, Robert Ansel wrote:
> Hello,
> 
> I'm looking for some help sorting out an apparmor conundrum.
> 
> We're following the Full System Policy approach described here <https://gitlab.com/apparmor/apparmor/-/wikis/FullSystemPolicy>. It's been working fine on Ubuntu 18.04, and we're working on an upgrade to 22.04, but when we try to apply the same profile and initramfs build method on 22.04 it fails to attach to PID 1 systemd.
> 

This method is no longer recommended, and there may be some revisions to initramfs tooling that is needed.

We now recommend using early policy load in systemd see https://gitlab.com/apparmor/apparmor/-/wikis/AppArmorInSystemd


> The method we're using now on 18.04 is essentially exactly what's being described on the wiki, except that, as described in the last bullet of the Troubleshooting section, we first install a stub profile and policy at boot, with the attach_disconnected flag, followed by initial configuration/chef-runs that quickly update that stub profile with the detailed allowlist for the host.
> 
> On 18.04 our profile is attached to /lib/systemd/systemd, but we weren't seeing success on 22.04 so we tried migrating it to /usr/lib/systemd/systemd to account for the symlink at `/lib` and provide the normalized path, but what we're seeing is that PID 1 is still unconfined on the host and the only thing being confined by our policy is the `systemd --user` process with another PID, which obviously doesn't act as a Full System Policy.
> 
> Wondering if you've seen this before or if you have any ideas to help debug why PID 1 isn't getting the profile, despite being launched at the same path from the same initramfs.
> 
I haven't but it has been years since I tried using the initramfs to apply policy.

> Thanks for any assistance you can provide and happy to come up with any extra debugging information you might find useful.
> 
> - Ransel
> 
> -- 
> 
> ---
> Robert S. Ansel