Page MenuHomePhabricator

understand / consider systemd ApparmorProfile= option
Closed, ResolvedPublic

Description

Once Whonix will be based on Debian version 9 codename 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.

onion-grater (Control Port Filter Proxy)'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 -?

Details

Impact
Normal

Event Timeline

Patrick raised the priority of this task from to Normal.
Patrick updated the task description. (Show Details)
Patrick set Impact to Normal.
Patrick added subscribers: Patrick, HulaHoop, nrgaway and 2 others.

What's the ApparmorProfile= option good for?

I'm still unsure as to the exact benefits from it but upstream decided to go with it in their Tor service file. I was going to ask for more information but OFTC has been out the whole day.

https://trac.torproject.org/projects/tor/ticket/8368

Looks like this option is not implemented.
Added

AppArmorProfile=/etc/apparmor.d/usr.sbin.cpfpd

in control-port-filter-python.service. It works as expected.
But with a typo

AppArmorProfile=/etc/apparmor.d/usr.sbin.cpf

It still works. sudo service control-port-filter-python status reports active (running), and the process is still enforced.

Jessie has systemd 215, meaning this *should* be in there. If its not working its probably a bug.

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.

Yes, AppArmorProfile= is >= Debian version 9 codename 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 version 9 codename 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".

Patrick renamed this task from systemd ApparmorProfile= option to understand / consider systemd ApparmorProfile= option.Feb 10 2016, 1:38 AM
Patrick closed this task as Resolved.
Patrick claimed this task.

T355#5608 should be a good enough summary. And done. Nothing left to do here.