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