Date: Sat, 23 Nov 1996 20:50:12 -0700 (MST) From: Marc Slemko <marcs@znep.com> To: Mikael Karpberg <karpen@ocean.campus.luth.se> Cc: Warner Losh <imp@village.org>, freebsd-hackers@freebsd.org Subject: Re: non-root users binding to ports < 1024 Message-ID: <Pine.BSF.3.95.961123203718.5433C-100000@alive.ampr.ab.ca> In-Reply-To: <199611240307.EAA06738@ocean.campus.luth.se>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 24 Nov 1996, Mikael Karpberg wrote: > I might be wrong, but doesn't rlogin for example bind to a port < 1024 > on OUTGOING connections, to make itself trustworthy? It's setuid root, > and could be just setuid bindlow or some other normal user, that would just > have one extra permission: To bind to all ports < 1024, special sensitive > ports excluded. I'm user more programs then rlogin could use that user also. rlogin calls rcmd(3). rmcd binds to a port determined by the rresvport(3), which is currently a port < 1024 but > 512. > If someone exploits a security hole in rlogin, they don't get as big an > advantage, since they can only bind to port < 1024, and none of the really > "interesting" ones (telnetd, rlogind, ftpd, etc). > > As I see it, any unneccesary priviliges to setuid programs is just asking > for trouble. > > Now the question: How do we implement such a feature? > I don't know exactly how IPFW works, but wouldn't we do about the same thing > with this feature (I'm guessing ipfw reads commandline data and uses it for > a sysctl)? like: ipfw actually does a setsockopt(2), which has been modified in such a way so that information gets passed through to the ipfw routines, which then modify the filter rules. > /sbin/ipport add deny nobody tcp 1-65000, udp 1-65000 > /sbin/ipport add allow bindlow 30+ except 80, 113, 111, 510-515 > /sbin/ipport add allow smtpuser 25 > > (Hmm... I don't know... hope you get my meaning :) Interesting idea. Very interesting idea. Advantages: - it could perhaps integrate with ipfw at some level; at the very least code could be copied, so it wouldn't need to be an entirely new interface to the kernel. It could perhaps go as far as just being a few more commands to the existing ipfw, but that would require some thought. - allows for a far more complicated local policy than other methods of implementing it. Disadvantages: - I have heard rumors about certain people not liking the ipfw code and wanting it to be replaced by ipfilter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.961123203718.5433C-100000>