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

Re: [tor-bugs] #5220 [Tor Client]: Intelligently use capabilities/privileges and drop what we don't need for Debian Gnu/Linux

#5220: Intelligently use capabilities/privileges and drop what we don't need for
Debian Gnu/Linux
-------------------------+--------------------------------------------------
 Reporter:  ioerror      |          Owner:                   
     Type:  enhancement  |         Status:  needs_information
 Priority:  major        |      Milestone:  Tor: unspecified 
Component:  Tor Client   |        Version:  Tor: unspecified 
 Keywords:  security     |         Parent:  #5219            
   Points:               |   Actualpoints:                   
-------------------------+--------------------------------------------------
Changes (by rransom):

  * status:  new => needs_information


Comment:

 Replying to [comment:1 ioerror]:
 > For Gnu/Linux I think we should do something like:
 > 0) define the caps we need or expect - see 'man capabilities'
 > 1) ship an apparmor profile that matches 0)

 Can a non-root user apply an AppArmor profile to one of its processes?

 > 2) in tor, define the caps we need and drop to debian-tor keeping what
 we need

 This would result in Tor running with greater privileges than it does now.
 (Currently, Tor drops all capabilities when it changes its UID; what you
 describe would keep at least Tor's `CAP_NET_ADMIN` privilege so that it
 can bind its listeners after dropping privileges.  It could also bind
 listening sockets on ports 22 and 80.)

 > 2a) eg: load torrc, drop caps, parse torrc

 How does Tor know what privileges it needs to keep before it has parsed
 its torrcs?

 Why would Tor need to drop privileges before parsing a file which can only
 be written by the user with write access to the Tor binary?

 > 3) in each sub process (eg: tor-fw-helper) we drop caps the sub process
 doesn't need in whatever we have execed

 If Tor's subprocesses should run with restricted privileges, their
 privileges should be restricted ''before'' the exec call, not after it.

 > In the long term view, Nick and I suggest discussing with Christian
 Grothoff et al that we should switch to a multi-user/multi-process
 qmail/gnunet like system for different tasks we wish to perform.

 How do you propose to improve Tor's security by splitting its components
 across multiple processes/security contexts?

 (We need to split Tor into multiple processes for non-security reasons
 anyway -- we already know that the only way to make non-trivial pluggable
 transports deployable is to split Tor's existing link protocols into
 separate processes, and use the resulting interface for pluggable
 transports as well -- but that doesn't provide any security benefit.  See
 [http://cr.yp.to/papers.html#qmailsec] for some discussion of how to use
 privilege separation usefully.)

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5220#comment:2>
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