[apparmor] [PATCH] Native systemd support
Christian Boltz
apparmor at cboltz.de
Wed Oct 19 22:53:41 UTC 2016
Hello,
quick review - but I'd welcome if someone else also comments on this.
I know the biggest pitfalls, but I'm far from being a systemd expert ;-)
Am Mittwoch, 19. Oktober 2016, 10:45:53 CEST schrieb Goldwyn Rodrigues:
> This patch implements native systemd support for apparmor. This
> is performed and tested on opensuse 42.1. I think we can keep
> rc.apparmor.suse for a bit more time until we decide to
> fully retire it.
>
> Signed-off-by: Goldwyn Rodrigues <rgoldwyn at suse.com>
This patch looks much better than your submit request ;-)
Thanks for working on this!
> --- a/parser/Makefile
> +++ b/parser/Makefile
> @@ -314,11 +314,12 @@
>
> .PHONY: install-suse
> install-suse:
It's probably a good idea to move the sytemd stuff to the general
"install" section (or maybe "install-systemd" if we want to stay
flexible) instead of keeping it suse-specific.
> - install -m 755 -d $(DESTDIR)/etc/init.d
> - install -m 755 rc.apparmor.$(subst install-,,$(@))
> $(DESTDIR)/etc/init.d/boot.apparmor - install -m 755 -d
> $(DESTDIR)/sbin
> - ln -sf /etc/init.d/boot.apparmor $(DESTDIR)/sbin/rcapparmor
> - ln -sf rcapparmor $(DESTDIR)/sbin/rcsubdomain
We migth want to keep "rcapparmor", but as symlink to /usr/sbin/service
(that's something I can also do in the spec because it's (open)SUSE-
specific)
"rcsubdomain" is terribly old, and I doubt if someone still uses it, so
dropping it sounds OK. (Besides that, it wouldn't work if we symlink it
to /usr/sbin/service anyway.)
> + install -m 755 -d $(DESTDIR)/usr/lib/systemd/system/
> + install -m 755 -d $(DESTDIR)/usr/lib/systemd/scripts/
> + install -m 0444 apparmor.service $(DESTDIR)/usr/lib/systemd/system
> + install -m 0755 apparmor_start.sh $(DESTDIR)/usr/lib/systemd/scripts
> + install -m 0755 apparmor_stop.sh $(DESTDIR)/usr/lib/systemd/scripts
> + install -m 0755 apparmor_reload.sh
> $(DESTDIR)/usr/lib/systemd/scripts
No objections to that path, but we already have /usr/share/apparmor/.
Would storing the scripts there make sence, or is it a bad idea?
> --- /dev/null
> +++ b/parser/apparmor.service
> @@ -0,0 +1,16 @@
> +[Unit]
> +Description=Load AppArmor profiles
> +DefaultDependencies=no
> +Before=sysinit.target
> +After=systemd-journald-audit.socket
> +ConditionSecurity=apparmor
> +
> +[Service]
> +Type=oneshot
> +ExecStart=/usr/lib/systemd/scripts/apparmor_start.sh
> +ExecReload=/usr/lib/systemd/scripts/apparmor_reload.sh
> +ExecStop=/usr/lib/systemd/scripts/apparmor_stop.sh
> +RemainAfterExit=yes
> +
> +[Install]
> +WantedBy=multi-user.target
Looks mostly like the current openSUSE apparmor.service (which is known
to work), with Exec* adjusted to your new scripts.
FYI: You aren't the only one who started working on apparmor.service.
Several other distributions have their own variants of it, see
- https://bugs.launchpad.net/apparmor/+bug/1503762/
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796589
- https://bugs.gentoo.org/show_bug.cgi?id=555388
- https://aur.archlinux.org/packages/apparmor/ (git clone to get the
files)
I don't know the state of each of them, and it shouldn't stop us from
getting apparmor.service into the upstream release. Nevertheless it
might be a good idea to have a look at each of them, especially when it
comes to the dependencies (for example, the Debian maintainer thinks
After=systemd-journald-audit.socket is superfluous and dropped it).
Ideally we can agree on an apparmor.service that all distributions can
and will use ;-)
> --- /dev/null
> +++ b/parser/apparmor_reload.sh
> @@ -0,0 +1,4 @@
> +#!/bin/bash
> +
> +/usr/lib/systemd/scripts/apparmor_stop.sh
That's a very bad idea - unloading the profiles means you remove the
AppArmor confinement from all running processes, and...
> +/sbin/apparmor_parser -r /etc/apparmor.d
... afterwards the profiles get loaded again, but will NOT be applied to
running processes (= leaving them unconfined!)
It's already bad enough if someone accidently uses "systemctl restart
apparmor" or "rcapparmor restart" (which gets mapped to stop, then
start) [1], but adding the same mistake to the reload script would be a
bad idea ;-)
Only profiles that no longer exist in /etc/apparmor.d/ should be unloaded
on reload. Have a look at /lib/apparmor/rc.apparmor.functions and the
current initscript for details.
> --- /dev/null
> +++ b/parser/apparmor_start.sh
> @@ -0,0 +1,4 @@
> +#!/bin/bash
> +/sbin/apparmor_parser -r /etc/apparmor.d
Looks good.
> --- /dev/null
> +++ b/parser/apparmor_stop.sh
> @@ -0,0 +1,20 @@
> +#!/bin/bash
> +SECURITYFS=/sys/kernel/security
> +APPARMOR_MOUNTPOINT=$SECURITYFS/apparmor
> +
> +if [ ! -w "$APPARMOR_MOUNTPOINT/.remove" ] ; then
> + exit 1
> +fi
> +
> +PROFILES=`sed -e "s/ (\(enforce\|complain\))$//"
> $APPARMOR_MOUNTPOINT/profiles` +
> +retval=0
> +for profile in $PROFILES; do
> + echo -n "$profile" > $APPARMOR_MOUNTPOINT/.remove
> + rc=$?
> + if [ ${rc} -ne 0 ]; then
> + retval=${rc}
> + fi
> +done
> +exit $retval
Looks good at the first view, but I'll have to compare it with the
existing scripts to be sure.
Regards,
Christian Boltz
[1] If you know any way to convince the systemd devs to add an
ExecRestart= option that can overrite the "stop, then start" default
behaviour, please do that. I already tried without success :-(
--
Du willst von SATA (alt, 7.200 RPM) jetzt gleich auf SSDs (!) im RAID50
(!!!!)?
Meinst Du nicht, Papierflieger und Überschalljet gäbe es noch ein paar
sinnvolle filligranere Abstufungen? [Peer Heinlein in postfixbuch-users]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20161020/4a13fc10/attachment.pgp>
More information about the AppArmor
mailing list