Date: Fri, 28 Mar 1997 18:54:19 -0600 (CST) From: "Thomas H. Ptacek" <tqbf@enteract.com> To: marcs@znep.com (Marc Slemko) Cc: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Subject: Re: Privileged ports... Message-ID: <199703290054.SAA13470@enteract.com> In-Reply-To: <Pine.BSF.3.95.970328160520.22468M-100000@alive.znep.com> from "Marc Slemko" at Mar 28, 97 04:14:43 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 This is a moot point. I don't think anyone has made any comments that really indicate that using inetd as a form of port access-control is feasible. > 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. This is not news, and isn't particularly germane to this discussion. Obviously, UDP/TCP 2049 is a problem; it's been brought up in quite a few discussion (though not this one) with respect to privileged port security (the SO_REUSEADDR/specific-bind thing last year leaps to mind). It is, however, interesting to note (as Mr. de Raadt did rather forcefully with me) that opening up the privileged port range to arbitrary users will probably subvert NFS in subtle ways; for instance, the portmapper is now fair game for attackers, and the possibility of NFS/portmapper dependancies needs to be addressed. However, I'll again re-assert that this isn't something I'm trying to solve; the patch I posted simply allows a different user besides root to bind privileged ports. I have yet to suggest that *every* user be able to do so, which is an impression I think many people are getting. Something that is probably worth discussing is the security of UID 0, compared to the security of any other arbitrary UID on the system. Is it safer to run a process as UID 0 (certain system calls could potentially check that a process is running as superuser and return EACCESS) than with any other credentials? > 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. I think anyone trying to implement that change would have noticed rather quickly that this is the case; whether FreeBSD is completely set up to drop that code in right now is irrelevant. Should the kernel check the owner of a socket, currently bound, if something else is trying to manipulate a potentially conflicting socket address? If this is the case, we should get that code working. If not, we should move on. Neh? [ re: ramifications of REUSEPORT and socket UID checks ] > 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. The idea behind REUSEPORT is to allow multiple processes to read incoming packets, implementing something of a socket-level broadcasting facility. It seems to me that forcing all such sockets to be of the same credentials unreasonably restricts the usefulness of this feature. ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703290054.SAA13470>