ID: 355PHID: PHID-TASK-eguhfbdj3ifhqkl23cy3Author: PatrickStatus at Migration Time: resolvedPriority at Migration Time: Normal
Once #Whonix will be based on #Debian_Stretch , #systemd will provide an ApparmorProfile= option.
Quoted from https://wiki.debian.org/AppArmor/Progress:
Integrate with systemd by: waiting for systemd v210+, which has a ApparmorProfile= option, or ship upstart’s /lib/init/apparmor-profile-load as an apparmor helper script and call it in systemd’s ExecPreStart=
Quoted from http://manpages.debian.org/cgi-bin/man.cgi?&query=systemd.exec:
AppArmorProfile=
Takes a profile name as argument. The process executed by the unit
will switch to this profile when started. Profiles must already be
loaded in the kernel, or the unit will fail. This result in a non
operation if AppArmor is not enabled. If prefixed by "-", all
errors will be ignored.
#control-port-filter-python ’s AppArmor profile /etc/apparmor.d/usr.sbin.cpfpd is effective without that option. One can verify that by test wise out commenting something form the profile. After reboot, denied messages would pop up.
TODO #research:
What’s the ApparmorProfile= option good for?
Should we use it?
Should we prefix by -?
2015-06-18 01:26:15 UTC
2015-06-18 21:05:22 UTC
Looks like this option is not implemented.AppArmorProfile=/etc/apparmor.d/usr.sbin.cpfpdcontrol-port-filter-python.service. It works as expected.AppArmorProfile=/etc/apparmor.d/usr.sbin.cpfsudo service control-port-filter-python status reports active (running), and the process is still enforced.
2015-06-19 16:31:13 UTC
2015-06-19 17:01:09 UTC
Progress information on this feature in Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760526
Yes there was a bug with the filesystem protections of apparmor and systemd conflicting. Improvements were added upstream in both projects but came late for the Jessie merge window.
To understand more the purpose of this feature please read the mail list discussion.
2015-06-20 19:51:51 UTC
Yes, AppArmorProfile= is >= #Debian_Stretch only.
I think I now understand what’s it about. It’s useful if we wanted to contain a daemon but not maintain a system wide apparmor profile for that daemon. Such as Debian’s system_tor profile for Tor. It apparmor-contains the daemon, but starting the daemon manually from the command line is unsupported by that profile.
Our options once using #Debian_Stretch .
a) dh-apparmor way
Use dh-apparmor.
Not using systemd’s AppArmorProfile=
Ship “global” profiles.
Like we currently do with cpfpy in Whonix 11.
b) systemd’s AppArmorProfile= way
Not using dh-apparmor.
Using systemd’s AppArmorProfile=
We ship system profiles only (example: system_cpfpy).
With our current method a) that we are using for cpfpy, there is a “bug”. Users could not easily start secondary instances of cpfpy from command line with separate options while profiting from AppArmor. That use case isn’t needed. No one ever required that. Method b) would be a bit more correct. It would be more clear, that we only support the AppArmor use case in context of the default systemd unit file. The “missing feature” would then be "you only have a “system” AppArmor profile, no “global” one. Not “perfect” either way, but certainly good enough for a long time either way, looks like. (Also “perfect” here would mean a code and support for stuff that one one even raised.)
With our current daemons, AppArmor profiles and users this whole thing is a corner case. I recommend we just leave it as it - because it works - until it comes up and/or just say “patches welcome”.
2016-02-10 00:38:08 UTC
2016-02-10 00:40:00 UTC