Re: pledge tor
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?
...it's not even chrooted?! I mean, that isn't perfect
either, but...layers...
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).
Re: pledge tor
On Tue, 19 Jan 2016 14:35:24 +, 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?
>
> ...it's not even chrooted?! I mean, that isn't perfect
> either, but...layers...
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).
>
>
Re: pledge tor
> On Tue, 19 Jan 2016 14:35:24 +, 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?
> >
> > ...it's not even chrooted?! I mean, that isn't perfect
> > either, but...layers...
>
> 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.
Re: pledge tor
On Tue, Jan 19, 2016 at 02:35:24PM +, 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.
