Opened 4 years ago
Last modified 6 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 follow-up: 2 Changed 4 years ago by
comment:2 Changed 4 years ago by
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
Cc: | proper added |
---|
comment:4 follow-up: 6 Changed 4 years ago by
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 follow-up: 7 Changed 4 years ago by
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 Changed 4 years ago by
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 Changed 4 years ago by
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
Milestone: | → Tor: 0.2.??? |
---|
comment:9 Changed 4 years ago by
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?
comment:11 Changed 3 years ago by
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 3 years ago by
Keywords: | tor-03-unspecified-201612 removed |
---|
Remove an old triaging keyword.
comment:13 follow-up: 14 Changed 2 years ago by
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 Changed 2 years ago by
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:16 follow-up: 17 Changed 6 months ago by
This ticket might be resolved (from our side) if we resolve #30797?
comment:17 Changed 6 months ago by
comment:18 Changed 6 months ago by
Parent ID: | → #30797 |
---|
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?)