systemd unit file is not compatible with the AppArmorProfile= directive

[intrigeri]

If I add the AppArmorProfile=system_tor directive to the unit file on current Debian sid, tor doesn't start and I get:

tor.service: Failed at step APPARMOR spawning /usr/bin/tor: Read-only file system

As discussed on the systemd mailing-list last year (​http://lists.freedesktop.org/archives/systemd-devel/2014-October/023909.html), setting up AppArmor confinement requires /proc to be writable.

And indeed, adding ReadWriteDirectories=-/proc fixes this problem for me. I intend to ask weasel to enable the AppArmor profile back in Debian (which we lost when migrating to systemd), so my question is: do you want ReadWriteDirectories=-/proc upstream (as a way to ease the work for downstreams who want to enable AppArmor confinement), or should we add it to the Debian delta?

[nickm]

I'd be happy to have our systemd profile work with AppArmor. Quick question though: does it really need write access to *all* of proc? (Or is the subset of proc that it needs so complex that really we can't limit it?)

[intrigeri]

Replying to nickm:

I'd be happy to have our systemd profile work with AppArmor.

:)

Quick question though: does it really need write access to *all* of proc? (Or is the subset of proc that it needs so complex that really we can't limit it?)

My understanding of the code (keep in mind that I'm no C programmer) is that to set the AppArmor profile (with aa_change_onexec), systemd only needs write access to /proc/PID/attr/current. But systemd's namespacing (including ReadWriteDirectories and friends) is applied earlier, that is at a time when we don't know the PID yet. So, sadly I don't see how we could give write access to only a subset of proc here.

To sum up:

• For AppArmor users, the proposed change will be an improvement (they'll get slightly weaker protection from systemd, but finer grained confinement from AppArmor which largely compensates the former).
• For non-AppArmor users, the proposed change indeed increases the attack surface a bit. I lack the low-level skills to quantify this, though: given the system-wide tor daemon is typically run as a dedicated user, in practice having write access to /proc means having write access only to files in /proc/PID/ that are owner-writable (modulo kernel bugs). I don't know how much this opens the attack surface in practice.

I'll let better skilled people than me evaluate if the former is worth the latter.

[nickm]

Hmmm. I think that if we do conclude that this will make things worse for non-apparmor users, we should maybe add it in a commented-out state, and have maintainers for apparmor-using systems enable it specifically?

[proper]

Or have some package, such as ​https://packages.debian.org/search?keywords=apparmor-profiles perhaps or Debian's tor package, drop a systemd override file? Roughly like this:

/lib/systemd/system/tor.service.d/40_apparmor-profiles.conf

[Service]
...

[intrigeri]

Replying to nickm:

Hmmm. I think that if we do conclude that this will make things worse for non-apparmor users, we should maybe add it in a commented-out state, and have maintainers for apparmor-using systems enable it specifically?

Sounds good.

[intrigeri]

Replying to proper:

Or have some package, such as ​https://packages.debian.org/search?keywords=apparmor-profiles perhaps or Debian's tor package, drop a systemd override file?

I'll discuss the Debian side of things with weasel on the Debian BTS.

[cypherpunks]

Hi,
I am updating several nodes from Ubuntu 15.04 with Tor 0.2.6.7 or 0.2.6.10 (from Tor experimental repo) to Ubuntu 15.10 with Tor 0.2.7.4-rc (experimental repo as well). On some nodes this works great, but on others Tor doesn't start afterwards with the error systemd[12345]: tor@default.service: Failed at step APPARMOR spawning /usr/bin/tor: No such file or directory in the syslog.
Purging Tor and reinstalling doesn't change anything. Where would I have to add ReadWriteDirectories=-/proc? In /lib/systemd/system/tor.service or in /etc/apparmor.d/system_tor or /etc/apparmor.d/abstractions/tor? The output of "systemctl status tor" seems to be fine and nothing at all is written to the Tor logfile. Any ideas?

[teor]

Milestone renamed

[nickm]

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

[nickm]

Remove an old triaging keyword.

[nickm]

Is there any way we can devolve responsibility here to the distributors? I don't think we have anybody on the core tor programming team who is expert in systemd or apparmor.

[intrigeri]

Replying to nickm:

Is there any way we can devolve responsibility here to the distributors? I don't think we have anybody on the core tor programming team who is expert in systemd or apparmor.

My historical background/perspective: before the tor package in Debian shipped any systemd unit file, I've put quite some energy into making the upstream unit file good enough for my taste. And then weasel (probably with good reasons) forked that unit file into a new one, that's now part of the Debian packaging and lives its happy life independently from the unit file shipped upstream. As I'm working with Debian systems, this implies that I now have no interest anymore in the upstream unit file: I would not benefit from any improvements made there unless someone manually synchronizes these changes to the Debian version from time to time. So to be clear: don't count on me to work on the upstream unit file again, sorry!

If any other distro maintainer ships the upstream unit file _and_ cares about AppArmor, then they would be well suited to take care of this ticket. If this person doesn't exist, then I suggest we simply give up and reject this ticket.

[traumschule]

group tickets related to AppArmorForTBB/tor packages

[arma]

This ticket might be resolved (from our side) if we resolve #30797?

[intrigeri]

Replying to arma:

This ticket might be resolved (from our side) if we resolve #30797?

Absolutely.