Intelligently use capabilities/privileges and drop what we don't need for Debian Gnu/Linux
This is the ticket where we will discuss caps/privs stuff on Gnu/Linux with a distinct preference for Debian.
Activity
changed milestone to %Tor: unspecified
For Gnu/Linux I think we should do something like: 0) define the caps we need or expect - see 'man capabilities'
- ship an apparmor profile that matches 0)
- in tor, define the caps we need and drop to debian-tor keeping what we need 2a) eg: load torrc, drop caps, parse torrc
- in each sub process (eg: tor-fw-helper) we drop caps the sub process doesn't need in whatever we have execed
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.
Replying to ioerror:
For Gnu/Linux I think we should do something like: 0) define the caps we need or expect - see 'man capabilities'
- ship an apparmor profile that matches 0)
Can a non-root user apply an AppArmor profile to one of its processes?
- 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_ADMINprivilege 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?
- 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.)
Trac:
Status: new to needs_informationHow do you propose to improve Tor's security by splitting its components across multiple processes/security contexts?
High level goals would be: Split network facing code from the rest and make it deprivileged. It would only have access to encrypted traffic coming in and out, no access to any keys, no access to the file system. Split relay, client, hidden service specific functions so they can not read each others keys, files, states, memory. Same with pluggable transport: It only accepts encrypted traffic and relays that to Tor. It doesn't need access to anything we care about, thus it mustn't be part of the TCB. This already is a "security reason".
Admittedly this is tricky because most code in Tor has to processes data coming in through the network and hardly anything doesn't have to have access to plain text communications or critical encryption keys. If the parts that can be deprivileged are too small you might even end up with a bigger TCB than before!
As an experiment, instead of splitting we add something: Let Tor come with it's own (deprivileged) application firewall/snort/IDS "protection daemon". It would check all incoming packets for irregularities and drop them. The only problem: To be of any use the daemon mustn't have access to the plain text, but you can only do so much filtering on encrypted traffic...
It would only have access to encrypted traffic coming in and out, no access to any keys, no access to the file system.
Do unix capabilities systems actually let you drop FS capabilities? As near as I can tell, on Linux, the only stuff in capabilities(7) is stuff that root is allowed to do.
Things like selinux and apparmor let you restrict programs more, but I don't know if there's a good way for a process to restrict itself.
Replying to cypherpunks:
How do you propose to improve Tor's security by splitting its components across multiple processes/security contexts?
High level goals would be: Split network facing code from the rest and make it deprivileged. It would only have access to encrypted traffic coming in and out, no access to any keys, no access to the file system. Split relay, client, hidden service specific functions so they can not read each others keys, files, states, memory.
Please explain in more detail so that someone can break this part.
Same with pluggable transport: It only accepts encrypted traffic and relays that to Tor. It doesn't need access to anything we care about, thus it mustn't be part of the TCB. This already is a "security reason".
A pluggable transport server has access to clients' IP addresses, can log the times, sizes, and directions of traffic burts, and can redirect all connections from new clients to an attacker-controlled relay for circuit-level traffic logging.
Admittedly this is tricky because most code in Tor has to processes data coming in through the network and hardly anything doesn't have to have access to plain text communications or critical encryption keys. If the parts that can be deprivileged are too small you might even end up with a bigger TCB than before!
Yes.
Please explain in more detail so that someone can break this part. I'm not familiar with the code base. But as I said, I have my doubts as well whether this strategy would work at all, except for the pluggable transport:
A pluggable transport server has access to clients' IP addresses, can log the times, sizes, and directions of traffic burts, and can redirect all connections from new clients to an attacker-controlled relay for circuit-level traffic logging.
Isn't that the same capabilities as the ISP already has? None of that, even combined necessarily breaks the user's security expectations. But they are broken if the transport server can be remotely exploited to phone home through a circuit as opposed to directly sending malformed packets as a neighboring node. Still, it "rises the bar". That's all we can hope for, till Tor is completely formally verified.
I think far more fruitful than introducing a multi-process architecture now is compiler hardening and thinking about the TorBrowser security architecture...
Trac:
Cc: nickm, arma to nickm, arma, tails@boum.org
Trac:
Cc: nickm, arma, tails@boum.org to nickm, arma, intrigerimentioned in issue #8195 (moved)
mentioned in issue #16161 (moved)
moved to tpo/core/tor#5220 (closed)