Date: Fri, 9 Jan 2009 13:29:11 -0500 From: "Adrian Chadd" <adrian@freebsd.org> To: "Max Laier" <max@love2party.net> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Julian Elischer <julian@elischer.org> Subject: Re: svn commit: r186955 - in head/sys: conf netinet Message-ID: <d763ac660901091029j40278b84p936d06dedbee6bfb@mail.gmail.com> In-Reply-To: <200901091909.00457.max@love2party.net> References: <200901091602.n09G2Jj1061164@svn.freebsd.org> <200901091802.10287.max@love2party.net> <49678D5E.3030600@elischer.org> <200901091909.00457.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/1/9 Max Laier <max@love2party.net>: > Speaking of disabling it ... setting the sysctl to 0 is not really enough to > do that. One would also have to walk through the active sockets and GC any > that are bound to nonlocal addresses to really disable it ... or do we rely on > tcpdrop or the like to do that manually? Of course it would make sense to > have something like this: start tproxy, bind forwarding ports, disable > sysctl, raise securelevel > > In addition, should there be a priv(9) check in ip_ctloutput? For which priv? Surely you don't really want people running services as root? :) gnn and I talked about this a bit on IRC, and I was waiting for rwatson to come online before posting a followup. Linux's implementation of this stuff uses the CAP_NET_ADMIN capability to define whether a process can do this or not. So users would start Squid as root, Squid would acquire CAP_NET_ADMIN, drop root, and then use it whenever required. Also, this is an option set on bind() on an outbound socket, not a listen() socket. You'd bind() to the client IP you're pretending to be, then connect() to the server destination. You can't raise securelevel/disable sysctl in the way you described. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d763ac660901091029j40278b84p936d06dedbee6bfb>