Opened 4 years ago

Last modified 3 months ago

#16782 new defect

systemd unit file is not compatible with the AppArmorProfile= directive

Reported by: intrigeri Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: systemd, apparmor, debian, packaging
Cc: proper Actual Points:
Parent ID: #30797 Points:
Reviewer: Sponsor:

Description

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?

Child Tickets

Change History (18)

comment:1 Changed 4 years ago by 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?)

comment:2 in reply to:  1 Changed 4 years ago by 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.

comment:3 Changed 4 years ago by proper

Cc: proper added

comment:4 Changed 4 years ago by 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?

comment:5 Changed 4 years ago by 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]
...

comment:6 in reply to:  4 Changed 4 years ago by 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.

comment:7 in reply to:  5 Changed 4 years ago by 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.

comment:8 Changed 4 years ago by teor

Milestone: Tor: 0.2.???

comment:9 Changed 4 years ago by cypherpunks

Severity: Normal

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?

Last edited 4 years ago by cypherpunks (previous) (diff)

comment:10 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:11 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

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

comment:12 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:13 Changed 2 years ago by nickm

Keywords: debian packaging added

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.

comment:14 in reply to:  13 Changed 2 years ago by 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.

comment:15 Changed 12 months ago by traumschule

group tickets related to AppArmorForTBB/tor packages

comment:16 Changed 4 months ago by arma

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

comment:17 in reply to:  16 Changed 3 months ago by intrigeri

Replying to arma:

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

Absolutely.

comment:18 Changed 3 months ago by teor

Parent ID: #30797
Note: See TracTickets for help on using tickets.