pledge tor

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

pledge tor

Carlin Bingham
The compat.c patch is by tb@ and stops tor from calling sysctl() to get
the total memory everytime it receives sighup, so we don't need `ps'
after tor_init().

I originally thought tor repeatedly called setgroups() but it does avoid
this so we don't need `id' after tor_init() either.

What's left we can't drop because tor's configuration can be changed
and reloaded while it's running.

rpath cpath wpath - tor reads, create and writes files in its data dir.

fattr - chowns and chmods various files and unix sockets.

dns - relays need dns and tor can be become a relay after startup.

inet - tor needs sockets.

unix - the socks and control ports can be set to use unix sockets

flock - locking file in the data dir.

getpw - gets ids to drop privs, chown files and answer GETINFO queries

proc exec - daemonising and pluggable transports

pf - tor supports transparent proxying to pf


Index: Makefile
===================================================================
RCS file: /var/cvs/ports/net/tor/Makefile,v
retrieving revision 1.88
diff -u -p -r1.88 Makefile
--- Makefile 10 Dec 2015 23:35:11 -0000 1.88
+++ Makefile 18 Jan 2016 23:43:03 -0000
@@ -6,11 +6,14 @@ DISTNAME= tor-0.2.7.6
 CATEGORIES= net
 HOMEPAGE= https://www.torproject.org/
 
+REVISION= 0
+
 MAINTAINER= Pascal Stumpf <[hidden email]>
 
 # BSD
 PERMIT_PACKAGE_CDROM= Yes
 
+# uses pledge()
 WANTLIB += c crypto event_core event_extra m pthread ssl z
 
 MASTER_SITES= https://www.torproject.org/dist/
Index: patches/patch-src_common_compat_c
===================================================================
RCS file: patches/patch-src_common_compat_c
diff -N patches/patch-src_common_compat_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_common_compat_c 19 Jan 2016 00:06:45 -0000
@@ -0,0 +1,41 @@
+$OpenBSD$
+--- src/common/compat.c.orig Tue Jan 19 01:04:16 2016
++++ src/common/compat.c Tue Jan 19 01:06:20 2016
+@@ -3228,23 +3228,25 @@ get_total_system_memory_impl(void)
+ #elif defined(HAVE_SYSCTL) && defined(INT64_HW_MEM)
+   /* On many systems, HW_PYHSMEM is clipped to 32 bits; let's use a better
+    * variant if we know about it. */
+-  uint64_t memsize = 0;
+-  size_t len = sizeof(memsize);
+-  int mib[2] = {CTL_HW, INT64_HW_MEM};
+-  if (sysctl(mib,2,&memsize,&len,NULL,0))
+-    return 0;
+-
++  static uint64_t memsize = 0;
++  if (memsize == 0) {
++    size_t len = sizeof(memsize);
++    int mib[2] = {CTL_HW, INT64_HW_MEM};
++    if (sysctl(mib,2,&memsize,&len,NULL,0))
++      return 0;
++  }
+   return memsize;
+
+ #elif defined(HAVE_SYSCTL) && defined(HW_PHYSMEM)
+   /* On some systems (like FreeBSD I hope) you can use a size_t with
+    * HW_PHYSMEM. */
+-  size_t memsize=0;
+-  size_t len = sizeof(memsize);
+-  int mib[2] = {CTL_HW, HW_USERMEM};
+-  if (sysctl(mib,2,&memsize,&len,NULL,0))
+-    return 0;
+-
++  static size_t memsize=0;
++  if (memsize == 0) {
++    size_t len = sizeof(memsize);
++    int mib[2] = {CTL_HW, HW_USERMEM};
++    if (sysctl(mib,2,&memsize,&len,NULL,0))
++      return 0;
++  }
+   return memsize;
+
+ #else
Index: patches/patch-src_or_main_c
===================================================================
RCS file: patches/patch-src_or_main_c
diff -N patches/patch-src_or_main_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_or_main_c 19 Jan 2016 00:06:29 -0000
@@ -0,0 +1,14 @@
+--- src/or/main.c.orig Wed Dec  9 15:25:24 2015
++++ src/or/main.c Tue Jan 19 00:50:23 2016
+@@ -3271,6 +3271,11 @@ tor_main(int argc, char *argv[])
+   if (tor_init(argc, argv)<0)
+     return -1;
+
++  if (pledge("stdio rpath cpath wpath fattr dns inet unix flock getpw proc exec pf", NULL) == -1) {
++    log_err(LD_BUG, "pledge: %s", strerror(errno));
++    return -1;
++  }
++
+   if (get_options()->Sandbox && get_options()->command == CMD_RUN_TOR) {
+     sandbox_cfg_t* cfg = sandbox_init_filter();
+


--
Carlin

Reply | Threaded
Open this post in threaded view
|

Re: pledge tor

Stuart Henderson-6
On 2016/01/20 02:04, Carlin Bingham wrote:
> pf - tor supports transparent proxying to pf

I think it would be reasonable to kill support for the DIOCNATLOOK
method for rdr-to, and only allow the pf-divert ("divert-to") method
that's used by spamd, ftp-proxy, squid, etc. It just uses getsockname()
to retrieve the original destination address, very straightforward.

They aren't being careful (see typo in connection_edge.c:1616).
Given the hostile environment this code is run in, do you really
want it having the ability to modify pf rules if attacked?

<looks more>...it's not even chrooted?! I mean, that isn't perfect
either, but...layers...<mutters something about onions>

There might be scope for further restrictions based on paths later
(depending on whether the whole thing can be limited to the data
dir, or whether it needs to read from some paths outside of it too).

Reply | Threaded
Open this post in threaded view
|

Re: pledge tor

Pascal Stumpf
On Tue, 19 Jan 2016 14:35:24 +0000, Stuart Henderson wrote:

> On 2016/01/20 02:04, Carlin Bingham wrote:
> > pf - tor supports transparent proxying to pf
>
> I think it would be reasonable to kill support for the DIOCNATLOOK
> method for rdr-to, and only allow the pf-divert ("divert-to") method
> that's used by spamd, ftp-proxy, squid, etc. It just uses getsockname()
> to retrieve the original destination address, very straightforward.
>
> They aren't being careful (see typo in connection_edge.c:1616).
> Given the hostile environment this code is run in, do you really
> want it having the ability to modify pf rules if attacked?
>
> <looks more>...it's not even chrooted?! I mean, that isn't perfect
> either, but...layers...<mutters something about onions>

Yep.  And the overall design is pretty hostile to pledge.  One process
doing everything (so you have ?path and inet in the same pledge), plus
features like config reload (meaning you cannot even drop privs that are
only needed for optional features, ugh).

Seriously, I think adding chroot support has a much lower
effort/usefulness rate at this point.  Adding a reasonably useful
pledge(2) (i.e. *not* pledge("everything")) is a lot harder and would
require a major redesign.  Also unlikely to be accepted by upstream.

> There might be scope for further restrictions based on paths later
> (depending on whether the whole thing can be limited to the data
> dir, or whether it needs to read from some paths outside of it too).
>
>

Reply | Threaded
Open this post in threaded view
|

Re: pledge tor

Theo de Raadt
> On Tue, 19 Jan 2016 14:35:24 +0000, Stuart Henderson wrote:
> > On 2016/01/20 02:04, Carlin Bingham wrote:
> > > pf - tor supports transparent proxying to pf
> >
> > I think it would be reasonable to kill support for the DIOCNATLOOK
> > method for rdr-to, and only allow the pf-divert ("divert-to") method
> > that's used by spamd, ftp-proxy, squid, etc. It just uses getsockname()
> > to retrieve the original destination address, very straightforward.
> >
> > They aren't being careful (see typo in connection_edge.c:1616).
> > Given the hostile environment this code is run in, do you really
> > want it having the ability to modify pf rules if attacked?
> >
> > <looks more>...it's not even chrooted?! I mean, that isn't perfect
> > either, but...layers...<mutters something about onions>
>
> Yep.  And the overall design is pretty hostile to pledge.  One process
> doing everything (so you have ?path and inet in the same pledge), plus
> features like config reload (meaning you cannot even drop privs that are
> only needed for optional features, ugh).
>
> Seriously, I think adding chroot support has a much lower
> effort/usefulness rate at this point.  Adding a reasonably useful
> pledge(2) (i.e. *not* pledge("everything")) is a lot harder and would
> require a major redesign.  Also unlikely to be accepted by upstream.

Another way to approach this is:

Don't pledge programs that don't want to be pledged.

In a few years, allow the list of programs which have been pledged,
essentially speak about the design of those programs.

One very complicated program is already on that list.  One could say
it was designed to be pledged / sandboxed / contained.  It isn't tor.

Reply | Threaded
Open this post in threaded view
|

Re: pledge tor

Jiri B-2
In reply to this post by Stuart Henderson-6
On Tue, Jan 19, 2016 at 02:35:24PM +0000, Stuart Henderson wrote:
> They aren't being careful (see typo in connection_edge.c:1616).
> Given the hostile environment this code is run in, do you really
> want it having the ability to modify pf rules if attacked?

Reported, see https://trac.torproject.org/projects/tor/ticket/18100

Thx!

j.