Summary: | sys-apps/apparmor doesn't include systemd units | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dainius Masiliūnas <pastas4> |
Component: | Hardened | Assignee: | Michael Palimaka (kensington) <kensington> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexandre.guimaraes, arthur, hardened, iskatu, systemd, v10lator |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://launchpad.net/bugs/1503762 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 448882 | ||
Attachments: |
apparmor@.service (without apparmor target)
apparmor.target apparmor@.service (with apparmor target) Example drop-in file (nginx.service.d/apparmor.conf) Example drop-in file (nginx.service.d/apparmor.conf) |
Description
Dainius Masiliūnas
2015-07-19 19:50:24 UTC
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(-) |