Page MenuHomePhabricator
Create Task
Maniphest T355

understand / consider systemd ApparmorProfile= option
Closed, ResolvedPublic
Actions

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 created this task.Jun 17 2015, 4:03 PM
Patrick raised the priority of this task from to Normal.
Patrick updated the task description. (Show Details)
Patrick added projects: AppArmor, Debian version 9 codename Stretch, systemd.
Patrick set Impact to Normal.
Patrick added subscribers: Patrick, HulaHoop, nrgaway and 2 others.
Herald added a project: Whonix. · View Herald TranscriptJun 17 2015, 4:03 PM
Herald added a subscriber: • WhonixQubes. · View Herald Transcript
HulaHoop added a comment.Jun 18 2015, 1:26 AM

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

troubadour added a comment.Jun 18 2015, 9:05 PM

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.

HulaHoop added a comment.Jun 19 2015, 4:31 PM

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

HulaHoop added a comment.EditedJun 19 2015, 4:47 PM

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.

Patrick added a comment.Jun 20 2015, 7:51 PM

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 added a comment.Feb 10 2016, 12:38 AM

A related issue....
systemd AppArmorProfile= directive unavailable leads to not loading AppArmor profile on Debian jessie:

Patrick renamed this task from systemd ApparmorProfile= option to understand / consider systemd ApparmorProfile= option.Feb 10 2016, 12: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.

Patrick removed Patrick as the assignee of this task.Feb 10 2016, 12:40 AM
Patrick added a project: Whonix 14.Jan 18 2017, 5:59 AM
Whonix OLD Issue Tracker · PLEASE DO NOT POST NEW TICKETS HERE · OLD Issue Tracker - Unread Notifications · OLD Issue Tracker - Feed · OLD Issue Tracker - Open Issues · NEW Issue Tracker · Homepage · Blog · Forum · Legal · Imprint · Privacy Policy · Terms of Use · Disclaimer