From owner-freebsd-hackers Sat Nov 23 19:51:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA25973 for hackers-outgoing; Sat, 23 Nov 1996 19:51:55 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA25964 for ; Sat, 23 Nov 1996 19:51:52 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id UAA25365; Sat, 23 Nov 1996 20:51:44 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id UAA07861; Sat, 23 Nov 1996 20:50:12 -0700 (MST) Date: Sat, 23 Nov 1996 20:50:12 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Mikael Karpberg cc: Warner Losh , freebsd-hackers@freebsd.org Subject: Re: non-root users binding to ports < 1024 In-Reply-To: <199611240307.EAA06738@ocean.campus.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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.