Date: Tue, 08 Apr 2008 10:29:05 -0700 From: Julian Elischer <julian@elischer.org> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: freebsd-net@freebsd.org, luigi@freebsd.org, oleg@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: ipfw uid/gid to match listening TCP sockets? Message-ID: <47FBAB61.2050604@elischer.org> In-Reply-To: <fbaf9b70804080543wf85de53hfe0f056a33f9e419@mail.gmail.com> References: <20080407081400.GA78448@dg.local> <20080408121535.D10870@fledge.watson.org> <fbaf9b70804080543wf85de53hfe0f056a33f9e419@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Yar Tikhiy wrote:
> On Tue, Apr 8, 2008 at 3:19 PM, Robert Watson <rwatson@freebsd.org> wrote:
>>
>> On Mon, 7 Apr 2008, Yar Tikhiy wrote:
>>
>>
>>> Our ipfw currently doesn't seem to match this host's traffic by uid/gid if
>> the traffic goes to a listening TCP socket. E.g., if one tries to allow
>> passive data connections to a local anonymous FTP server as follows, it
>> won't work:
>>> ipfw add 10000 allow tcp from any to me dst-port 49152-65535 uid
>> ftp in keep-state
>>> This behaviour is obvious from ip_fw2.c:
>>>
>>> 2009 if (proto == IPPROTO_TCP) {
>>> 2010 wildcard = 0;
>>> 2011 pi = &tcbinfo;
>>> 2012 } else if (proto == IPPROTO_UDP) {
>>> 2013 wildcard = INPLOOKUP_WILDCARD;
>>> 2014 pi = &udbinfo;
>>> 2015 } else
>>> 2016 return 0;
>>>
>>> I.e., it is OK for UDP to match PCBs (essentially sockets) with a wildcard
>> foreign (remote) address, but not for TCP.
>>> I wonder if there will be any security or whatever issues if the wildcard
>> flag is set for TCP, too. The only peculiarity I can see now is that
>> listening sockets shouldn't generate outbound traffic; as soon a 3-way
>> handshake starts, a separate PCB is created. Thus a listening socket can
>> match inbound packets only.
>>> Are there any other points I missed? Thanks!
>>>
>> None of this code really makes very much sense anyway, and is vulnerable to
>> a number of races and semantic inconsistencies, not to mention application
>> behavior that confuses it (such as sshd's opening forwarded sockets using a
>> privileged credential). I'm not sure I agree with your analysis that listen
>> sockets don't generate packets, btw: the syncache generates packets that are
>> not yet from a specific socket, so arguably they are from the listen socket.
>> All that said, I don't see any reason not to match listen sockets in the pcb
>> lookup here.
>
> Thank you for these points! Matching packets from listen sockets makes
> the case even simpler; then it's the matter of changing the "wildcard = 0;"
> to "wildcard = INPLOOKUP_WILDCARD;". At least matching listen sockets
> doesn't seem to break things not already broken.
>
>> Be aware that uid/gid/jail rules may become less maintainable as our TCP
>> locking becomes more mature. We already jump through some uncomfortable
>> hoops to keep it working, but I'm not sure how long that can go on.
>
> I've always viewed uid/gid rules as a hack that works for now. In the long run
> we may want to consider an API allowing privileged apps to punch holes
> in the firewall in a controllable manner. Of course, the API should be agnostic
> of the particular firewall type. Then, e.g., ftpd(8) would be able to
> open its current
> passive data port only and to a single remote IP, and the whole port
> range wouldn't
> need to be exposed. Such holes could be handled as dynamic rules/states so that
> they don't stay there forever if the app crashes.
we use these rules in a totally different manner... i.e. so one
'replacement' may not suit all users.. only people that use it in
that manner.
how we use it:
transparent redirection for a proxy, where the proxy is pretending to
be the client....
fwd 127.0.0.1:80 tcp from any 80 to any in recv ${outside_iface} uid
${proxy_uid}
If the proxy has a socket that matches the packet it gets captured,
even if there is no other reason tho think it would be local..
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47FBAB61.2050604>