From owner-freebsd-security Wed Mar 26 06:25:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA11006 for security-outgoing; Wed, 26 Mar 1997 06:25:36 -0800 (PST) Received: from obiwan.aceonline.com.au (obiwan.aceonline.com.au [203.103.90.67]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA10994 for ; Wed, 26 Mar 1997 06:25:19 -0800 (PST) Received: from localhost (adrian@localhost) by obiwan.aceonline.com.au (8.8.5/8.8.5) with SMTP id WAA29204; Wed, 26 Mar 1997 22:19:55 +0800 (WST) Date: Wed, 26 Mar 1997 22:19:55 +0800 (WST) From: Adrian Chadd To: David Greenman cc: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Subject: Re: Privileged ports... In-Reply-To: <199703260733.XAA10931@root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 25 Mar 1997, David Greenman wrote: > >As part of a gradual effort to rid my kernel of suser() calls, I whipped > >up a quick patch to in_pcb.c that configurably removes the superuser > >restriction on binding privileged ports. > > Hmmm... > >This has the effect of removing the requirement for programs like rlogin > >and rsh to run with superuser privs, thus eliminating a few more SUID > >programs. In place of suser(), I've inserted two new sysctl OIDs under > > ...and creating a gaping security whole at the same time. I sure hope > you're not doing this on any shell account machines and you completely > trust any users that you have. > Agreed. I'm going to fiddle with this, but I have been fiddling with Linux's Transparent Proxy support (IPFilter does something similar), and redirecting traffic to a certain port (the one I'm working on is sendmail) to a non-priv'ed port. The original idea was running a socket redirector (which, although SUID, is quite small and much easier to secure), redirecting traffic to the not-suid-anymore program, however doing it in kernelland appeals much more to me. The only problem here is that it kinda defeats the whole purpose of prived ports in the first place. I guess the whole thing here is to write small programs that do the necessary SUID bit, then drop back down into nonrootland to continue. David (and anyone else interested) - I'd be very interested in hearing what security holes would be introduced by having a UID (or GID) to bind to priv'ed ports. Surely there must be a nicer way :) Adrian Chadd