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