From owner-freebsd-security Fri Mar 28 11:22:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA28145 for security-outgoing; Fri, 28 Mar 1997 11:22:43 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA28139 for ; Fri, 28 Mar 1997 11:22:39 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.7.3) with UUCP id MAA22865; Fri, 28 Mar 1997 12:22:24 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id MAA22813; Fri, 28 Mar 1997 12:18:33 -0700 (MST) Date: Fri, 28 Mar 1997 12:18:33 -0700 (MST) From: Marc Slemko To: Brandon Gillespie cc: freebsd-security@FreeBSD.ORG Subject: Re: alternate approach (Re: Privileged ports...) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk That is one possible solution, but I don't think there is any point in adding such a specific config file when so many other things could benefit from similar functionality. It is a dupe of sysctl in a lot of ways, so it may be an ide ato look at extending sysctl to handle it nicely. You need some interface to the kernel; some program like ipfw that goes through the file and reads the rules and sets them up in the kernel. This program could be used for a lot of things; a good project would be extending sysctl to allow for less rigidly defined variables. eg. can define ranges, variables that don't show up in a list until changed, having sysctl being able to read variables from a file (although this can be done now with a script, just isn't as nice... To summarize: good idea, lots of things like that, but as I have been saying all along we need a better generalized interface to such things because it makes little sense to keep adding little control programs here and there. Perhaps someday.... On Fri, 28 Mar 1997, Brandon Gillespie wrote: > I know I'm jumping into this a bit late, but a while back I suggested > something similar, which I think would work as well in this situation. > Its along the same lines of defining the allowed user (and possibly group) > in inetd.conf, but why do it there? I would suggest doing it to another > file, such as /etc/services, or something similar, and just having it be a > generic port configuration file overall. This file would define who can > use what ports up to 1024, and it would also open up ports beyond 1024. > This would have the added benefit that admins could reconfigure it to not > allow general users to bind to ANY ports, period--if they are having > problems with generic users throwing up disallowed network daemons. The > format could be very simple, such as: > > PORTSPEC user group > > Where portspec is simply a single port, or range of ports given as the > actual port number or name, as specified in /etc/services, examples: > > 1-79 root system > http webadm webadm > 81-1024 root system > > Or perhaps have a directive as the first 'word' on the line, so you could > expand on the functionality for different behaviour (also giving a default > for different ranges, so you could have overlapping declarations, such as > 1-1024 default to root:system and port 80 given to webadm). > > Just a thought. > > -Brandon Gillespie >