Opened 7 years ago

Closed 2 years ago

#5220 closed enhancement (duplicate)

Intelligently use capabilities/privileges and drop what we don't need for Debian Gnu/Linux

Reported by: ioerror Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Normal Keywords: security tor-client
Cc: nickm, arma, intrigeri Actual Points:
Parent ID: #5219 Points:
Reviewer: Sponsor:

Description

This is the ticket where we will discuss caps/privs stuff on Gnu/Linux with a distinct preference for Debian.

Child Tickets

Change History (12)

comment:1 Changed 7 years ago by 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)
2) in tor, define the caps we need and drop to debian-tor keeping what we need
2a) eg: load torrc, drop caps, parse torrc
3) 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.

comment:2 in reply to:  1 Changed 7 years ago by rransom

Status: newneeds_information

Replying to 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.)

comment:3 Changed 7 years ago by 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. 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...

comment:4 Changed 7 years ago by nickm

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.

comment:5 in reply to:  3 Changed 7 years ago by rransom

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.

comment:6 Changed 7 years ago by cypherpunks

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...

comment:7 Changed 7 years ago by cypherpunks

Do unix capabilities systems actually let you drop FS capabilities?

That's what permissions are for, no?

comment:8 Changed 7 years ago by T(A)ILS developers

Cc: tails@… added

comment:9 Changed 7 years ago by nickm

Keywords: tor-client added

comment:10 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:11 Changed 5 years ago by intrigeri

Cc: intrigeri added; tails@… removed

comment:12 Changed 2 years ago by nickm

Resolution: duplicate
Severity: Normal
Status: needs_informationclosed

This is superseded by our seccomp2 sandbox and our capabilities support on linux.

Note: See TracTickets for help on using tickets.