Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#12751 closed defect (implemented)

systemd unit file could use more filesystem namespace hardening options

Reported by: intrigeri Owned by: intrigeri
Priority: Medium Milestone: Tor: 0.2.6.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-relay systemd 025-backport
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

systemd has nice features to restrict what part of the filesystem a service has read-only or read-write access to (ReadOnlyDirectories, ReadWriteDirectories) that we could use. Also InaccessibleDirectories could be made a bit more restrictive.

Child Tickets

Change History (7)

comment:1 Changed 5 years ago by intrigeri

I'm experimenting locally with such hardening options, stay tuned. (Note that SystemCallFilter might be useful too, but I'll save it for a dedicated ticket, and not sure I'll have time to tackle it soon.)

comment:2 Changed 5 years ago by intrigeri

Status: newneeds_review

Implemented in the bug12751-systemd-filesystem-sandbox branch, repo https://git-tails.immerda.ch/tor.

comment:3 Changed 5 years ago by nickm

Keywords: tor-relay 025-backport added; tor-relays removed
Milestone: Tor: 0.2.6.x-final

Do we care about managed pluggable transports launched by the Tor process here? Do they inherit these restrictions?

Would you like to narrow read directories down as well? If so, see the list of stuff in the function sandbox_init_filter() in main.c. (Also please let me know if there's some reason that Tails can't enable "sandbox 1"; I want to fix it if there is.)

comment:4 in reply to:  3 Changed 5 years ago by intrigeri

Replying to nickm:

Do we care about managed pluggable transports launched by the Tor process here?

Good point. My answer is that we definitely care: I don't want relay operators to mentally associate "systemd" with "breaks stuff that used to work just fine". The transition should be as smooth as possible.

So, I have tested the proposed systemd unit files changes with obfsproxy (obfs3, scramblesuit) both on the client and relay sides.

This question of yours also had me write an AppArmor profile for obfsproxy to confirm that it doesn't need to access other parts of the filesystem than what the proposed systemd unit file allows (https://bugs.debian.org/739284), so I'm now reasonably confident we're not going to break these usecases here.

Do they inherit these restrictions?

I'm pretty sure they do, as the filesystem restrictions are implemented with Linux namespaces, and I don't see how a child process could escape it.

Would you like to narrow read directories down as well? If so, see the list of stuff in the function sandbox_init_filter() in main.c.

It could be a nice bonus, and I've tried it already, but my attempts at using a whitelist approach here (setting InaccessibleDirectories=/, and then adding the required directories to ReadOnlyDirectories) failed. I'll have to ask the systemd community for help on that one. I don't think that's a blocker, and I must say it's pretty low priority on my todo list: the usecases I'm most interested in also have AppArmor confinement profiles, or will have soonish.

(Also please let me know if there's some reason that Tails can't enable "sandbox 1"; I want to fix it if there is.)

I'll have a look and report back.

comment:5 Changed 5 years ago by nickm

Seems okay to me. Merging this.

comment:6 Changed 5 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

comment:7 Changed 5 years ago by nickm

If we backport this, also backport #13196

Note: See TracTickets for help on using tickets.