Comment 6 for bug 1503762

I doubt it's ideal to have apparmor_parser called from a service file to begin with. AppArmor protects specific processes, and often times said processes are already started by systemd. There is an AppArmorProfile directive in systemd already, but unfortunately it just switches profiles instead of loading them. Having something akin to that, which both loads a profile and makes sure not to load the daemon if the profile it's associated with isn't loaded, would be nice. That would allow systemd to handle the boot parallelisation as well as security, both things that only PID1 can really be trusted to do right.

In the mean while, I'm using templates for handling that, with an apparmor.target for managing them all at the same time:

  [Unit]
  Description=AppArmor target
  DefaultDependencies=no
  Before=sysinit.target

  [Install]
  WantedBy=sysinit.target

And the template unit apparmor@.service:

  [Unit]
  Description=AppArmor profile: %i
  DefaultDependencies=no
  Before=apparmor.target

  [Service]
  Type=oneshot
  ExecStart=/sbin/apparmor_parser -r /etc/apparmor.d/%i
  ExecStop=/sbin/apparmor_parser -R /etc/apparmor.d/%i
  ExecReload=/sbin/apparmor_parser --reload /etc/apparmor.d/%i
  RemainAfterExit=yes

  [Install]
  WantedBy=apparmor.target

This does mean that you initially need to either manually specify each profile to load (using `systemctl enable <email address hidden>` for instance, which is fairly inefficient since it passes files to the parser one by one), and/or use a drop-in, like nginx.service.d/01-apparmor.conf:

  [Unit]
  <email address hidden>
  <email address hidden>

Which is quite nice, since it ensures that the service, when enabled and run, will make sure to load its own profile, or refuse to run if it fails to load. In this case the loading can happen at any time during boot, it doesn't have to be early boot. But it does mean that you need a drop-in file for every protected service.