From owner-freebsd-security Thu Mar 27 09:53:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA02796 for security-outgoing; Thu, 27 Mar 1997 09:53:38 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA02760 for ; Thu, 27 Mar 1997 09:53:32 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id FAA03815 for ; Thu, 27 Mar 1997 05:42:28 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.7.3) with UUCP id GAA05206; Thu, 27 Mar 1997 06:40:48 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id GAA13269; Thu, 27 Mar 1997 06:38:59 -0700 (MST) Date: Thu, 27 Mar 1997 06:38:58 -0700 (MST) From: Marc Slemko Reply-To: Marc Slemko To: "Thomas H. Ptacek" cc: freebsd-security@freebsd.org Subject: Re: Privileged ports... In-Reply-To: <199703261847.MAA28329@enteract.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 Wed, 26 Mar 1997, Thomas H. Ptacek wrote: > > for each low numbered port? It seems that (modulo configuration being > > a little painful) this offers the best of both worlds--control over > > low numbered ports, but anyone can bind to a port with root's > > Not only is inetd's configuration much longer, but if it dies (or, more > specifically, if an attacker can kill it), your system becomes completely > insecure. I think it's a bad idea to have security issues rely on the > survival of userland processes. > > Am I wrong? 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 sometimes sneak in; it is relatively secure by Unix standards but if you are doing things that way for security it isn't secure enough. The proper way is to simply make a program (or extend sysctl to deal nicely with large ranges where you don't want to normally show items that 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, although many of them can be implemented as sysctl variables right now without much hassle.