[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #12751 [Tor]: systemd unit file could use more filesystem namespace hardening options

#12751: systemd unit file could use more filesystem namespace hardening options
---------------------------+--------------------------------------------
     Reporter:  intrigeri  |      Owner:  intrigeri
         Type:  defect     |     Status:  needs_review
     Priority:  normal     |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor        |    Version:
   Resolution:             |   Keywords:  tor-relay systemd 025-backport
Actual Points:             |  Parent ID:
       Points:             |
---------------------------+--------------------------------------------

Comment (by intrigeri):

 Replying to [comment:3 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12751#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs