Re: ipfw uid/gid to match listening TCP sockets?

Yar Tikhiy wrote:
On Tue, Apr 8, 2008 at 3:19 PM, Robert Watson <rwatson@xxxxxxxxxxx> 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..




_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Http server implementation for Windows Media Server
    ... I'm assuming you are using a raw TCP ... Dump that idea and use a regular TCP socket instead. ... the packets aren't ACKed because ... since my Http server simulates for him a Windows Media ...
    (microsoft.public.win32.programmer.networks)
  • Re: Socket switch delay
    ... > I was referring to the client sending data on this socket while the server ... sockets to provide TCP support without also supporting asynchronous ... > The server uses blocking sockets just because I am also using Overlapped ... > structures to send the packets. ...
    (microsoft.public.win32.programmer.networks)
  • Socket Programming: How to terminate a thread "listening" for UDP packets?
    ... I have started out with socket programming by developing a little tool that will read a file transfer from telemetry. ... The first version is very rudimentary, meaning I do not control correct sequence of packets and missing packets, I just dump everything to a file. ... What I am trying to do is - I want to allow the user in a basic GUI to click on a button and toggle the program status between "listening" and "not listening" for new file transfers / packets. ...
    (comp.unix.programmer)
  • ipfw uid/gid to match listening TCP sockets?
    ... Our ipfw currently doesn't seem to match this host's traffic by ... uid/gid if the traffic goes to a listening TCP socket. ...
    (freebsd-net)
  • Re: Sockets Refresh Problem
    ... Can you post your code that reads data from the socket? ... In TCP, ... No, in TCP, *packets* are sent and received. ... packet's worth of data, ...
    (comp.unix.programmer)