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
