Date: Fri, 28 Mar 1997 16:14:43 -0700 (MST) From: Marc Slemko <marcs@znep.com> To: "Thomas H. Ptacek" <tqbf@enteract.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Privileged ports... Message-ID: <Pine.BSF.3.95.970328160520.22468M-100000@alive.znep.com> In-Reply-To: <199703281756.LAA22483@enteract.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Some mail I have been exchanging with Theo de Raadt has made it apparent that perhaps my suggestion could be taken in the wrong way. It is NOT really related to the question of having inetd bind to ports to prevent other processes from binding to them if you get rid of reserved ports, but is simply a general problem. It affects many processes including nfsd. Anyone feel like stealing traffic (or, more likely, worse...) from port 2049? No problem, any user can do that as things are now. I should also probably clarify that the suggested change is by no means complete, eg. you have to add the uid credential to sockets so you what uid bound to it in the first place to do the comparison. On Fri, 28 Mar 1997, Thomas H. Ptacek wrote: > > OpenBSD has the following in netinet/in_pcb.c: > > [ elided ] > > > To emphasize; right now, anyone can steal any connections going > > to an unprivileged port that inetd listens on, unless you use something > > like the -a option to inetd. That is bad. I think something > > resembling the above OpenBSD change is a good idea. Anyone? > > Isn't FreeBSD already doing a PCB lookup on attempts to bind specific > ports? Right under the privileged port check, it tries to find a PCB for > the sockaddr passed to bind(), and checks it for SO_REUSEPORT. You could > just stick the UID check in there, at no PCB lookup cost, neh? Except that doesn't always check for sockets bound to wildcard addresses (last parm to in_pcblookup) while we need to do that for the uid check. I see no obvious way to integrate the two calls; it could be implemented by rewriting in_pcblookup but that is a different matter... > > What are the ramifications of enforcing a UID check on a socket address > bound REUSEPORT, incidentally? Can't think of too many. If you had a program running from inetd that tried to bind to a port after being started you could run into some issues perhaps.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970328160520.22468M-100000>