AppArmor does not include systemd units, making it difficult to start with AppArmor enabled. Reproducible: Always Steps to Reproduce: 1. Install sys-apps/apparmor 2. Run `systemctl enable apparmor` or similar Actual Results: Unit is not found Expected Results: AppArmor profiles should be loaded on startup Upstream doesn't provide units yet, but a number of distributions provide their own ones (notably Arch: https://aur.archlinux.org/packages/apparmor/ ). The units aren't very difficult to maintain so there shouldn't be problems shipping them. Looking at how Arch does it, it looks a bit incorrect. For one, writing to a log file is bad, since journald captures all stderr by itself (and the wait for filesystem availability caused by that is not acceptable for something this critical). In addition, running scripts to launch it is needlessly fragile, and blindly adding every profile in /etc/apparmor doesn't sound like the best practice; templates can be used to add individual profiles instead. Finally, some thought should be put into making certain that profiles are loaded before the system boots. When systemd is installed with USE=apparmor, services can be taught to fail to start if their respective apparmor profiles are not loaded, increasing security in case something goes wrong. I'll test and attach the unit files I use in my personal system for this a bit later.
I don't use systemd so can't work on this.
Created attachment 407288 [details] apparmor@.service (without apparmor target) Attached the template service file I currently use for loading the profiles. It's used per-AppArmor-profile, as in: systemctl start apparmor@bin.ping to load the /etc/apparmor.d/bin.ping profile into the kernel. Each profile can be started, stopped, restarted, enabled and disabled individually. When enabled, the loading happens very early in the boot process, and any possible errors are logged by journald. To further improve this, I think an apparmor.target unit can be made, and the template changed to have WantedBy=apparmor.target, to get the ability to disable and re-enable all the service instances registered with systemd with a single command. In addition, some unit overrides could be used to force associated services not to start if the corresponding profiles aren't loaded for added security. I'll look into how best to achieve that a bit later.
Created attachment 407994 [details] apparmor.target This is the target file I use now. The nice thing about this is that it allows disabling and re-enabling all the defined AppArmor profile services at once by using `systemctl disable apparmor.target` and `systemctl enable apparmor.target`. I considered also adding `RequiredBy=basic.target` to the Install section, but that's probably too extreme (it would stop booting if there were any issues in the enabled AppArmor profiles and open a rescue shell instead).
Created attachment 407996 [details] apparmor@.service (with apparmor target) And the corresponding apparmor@.service to make use of the target.
Created attachment 408038 [details] Example drop-in file (nginx.service.d/apparmor.conf) And here's an example of a drop-in file that makes absolutely certain that a particular service doesn't even start if its AppArmor profile isn't loaded; and also automatically starts the AppArmor profile when attempting to load the associated service (however, this is not a substitute for enabling the AppArmor profile service, since that would leave manually launched instances vulnerable). That means that if there's something wrong with the profile or profile storage, the associated daemon doesn't start, but everything else does, allowing debugging without compromising security. Unfortunately there's no way to automate making such drop-in files, as far as I know, since one needs to know the service and profile names. Administrators should make such drop-in files themselves for each service that needs to be protected by AppArmor. Thankfully it's not particularly hard: `mkdir /etc/systemd/system/name.service.d`, `nano /etc/systemd/system/name.service.d/apparmor.conf` (or 01apparmor.conf or what have you), then fill in the three fields with the profile file name. The first two fields make sure the profile loading services are done, whereas the last one queries libapparmor itself to independently verify that the profile(s) loaded successfully (this particular functionality requires the "apparmor" USE flag to be enabled in systemd).
Created attachment 408118 [details] Example drop-in file (nginx.service.d/apparmor.conf) Attached a fixed example, the last one didn't actually do anything due to syntax errors. I removed the AppArmorProfile directive because for me it results in: Failed at step APPARMOR spawning /usr/sbin/nginx: No such file or directory I'm not sure what gives, since that file definitely exists. But maybe it gets confused, because that directive is for switching profiles, and this is switching to itself. Alternatively to something like this drop-in, the profile loading service could use RequiredBy= and Before= on the service it protects, but it would have to use drop-ins as well, so it doesn't really matter which solution is used.
@Dainius Masiliūnas I tried the last target and service files you attached and they seems to work, but when I restarted the system apparmor doesn't have any profile loaded any more. PS. what is the recommended practice to use the extra-profiles? I tried using symlinks to /etc/apparmor.d but won't work. Than did I copy the entire directory to there. Thanks!
Sorry, user error. I had enabled the profiles using the aa-enforce command instead the systemctl one.
Now, I think the best way to enable/disable apparmor profiles on Gentoo would be on the eselect way, but I can't help to implement it because I do not code.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=01417d76965fc9cb35171e72694562c71da537c5 commit 01417d76965fc9cb35171e72694562c71da537c5 Author: Reuben D'Netto <rdnetto@gmail.com> AuthorDate: 2017-12-06 11:12:46 +0000 Commit: Michael Palimaka <kensington@gentoo.org> CommitDate: 2017-12-07 09:49:01 +0000 sys-apps/apparmor: Added systemd unit. Closes: https://bugs.gentoo.org/555388 Closes: https://github.com/gentoo/gentoo/pull/6466 sys-apps/apparmor/Manifest | 2 +- sys-apps/apparmor/apparmor-2.11.1-r2.ebuild | 64 +++++++++++++++++++++++++++++ sys-apps/apparmor/files/apparmor.service | 14 +++++++ sys-apps/apparmor/files/apparmor_load.sh | 2 + sys-apps/apparmor/files/apparmor_unload.sh | 2 + 5 files changed, 83 insertions(+), 1 deletion(-)
