Date: Fri, 9 Jan 2009 20:08:05 +0100 From: Max Laier <max@love2party.net> To: "Adrian Chadd" <adrian@freebsd.org> 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: <200901092008.06049.max@love2party.net> In-Reply-To: <d763ac660901091029j40278b84p936d06dedbee6bfb@mail.gmail.com> References: <200901091602.n09G2Jj1061164@svn.freebsd.org> <200901091909.00457.max@love2party.net> <d763ac660901091029j40278b84p936d06dedbee6bfb@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 09 January 2009 19:29:11 Adrian Chadd wrote: > 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? :) You don't want your normal user to be able to bind to foreign addresses either. If you need to create sockets over and over again you use privilege separation as done in OpenBSD. > 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. I see ... though there is no restriction in your code yet that would prevent one from using it on a listen() socket. Can you hold off on further commits until we reach a consensus about how this should be done? This is getting a bit messy for my taste. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200901092008.06049.max>