Date: Thu, 27 Mar 1997 13:41:03 -0600 (CST) From: "Thomas H. Ptacek" <tqbf@enteract.com> To: marcs@znep.com Cc: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Subject: Re: Privileged ports... Message-ID: <199703271941.NAA23050@enteract.com> In-Reply-To: <Pine.BSF.3.95.970327063025.13195A-100000@alive.znep.com> from "Marc Slemko" at Mar 27, 97 06:38:58 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I agree completely with you. It is a very bad thing. Start with the fact > that, by default, inetd limits services to being called 256 times a minute > and then shuts them off and then move on to more devious ways you could inetd doesn't release the socket address when it shuts the port off, so I doubt you'd be able to bind over something inetd's handling. You do have a potential problem with specific binds (over inetd's INADDR_ANY) in this configuration, though. The real problem, as I see it, is that if reserved ports are enough of a security concern for you that you'd dramatically complicate your inetd configuration to handle them, you're going to have a real security concern if inetd dies. I think it's bad to assume that an unprivileged user can't cause a daemon to die. > are set to a particular default but still allow them to be changed) that > handles setting it then add a few lines of code to the kernel to allow you > to set the uid who can bind to each priv'd port. There are 1764 other > things that it would be useful to be able to set in a similar way, Why do you want a UID per reserved port? What is this getting you? ---------------- 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?199703271941.NAA23050>