From owner-freebsd-hackers Fri Nov 22 21:59:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA11351 for hackers-outgoing; Fri, 22 Nov 1996 21:59:20 -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 VAA11346 for ; Fri, 22 Nov 1996 21:59:11 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id WAA00277; Fri, 22 Nov 1996 22:57:52 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id WAA29691; Fri, 22 Nov 1996 22:56:55 -0700 (MST) Date: Fri, 22 Nov 1996 22:56:54 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Mark Newton cc: Peter Childs , freebsd-hackers@freebsd.org, miff@spam.frisbee.net.au Subject: non-root users binding to ports < 1024 (was: Re: BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2).) In-Reply-To: <9611212357.AA14971@communica.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This thread started in freebsd-security earlier in the week; it evolved from a discussion of the reasons why sendmail runs as root. The basic suggestion was to implement some system of allowing the specification of what non-root users could bind to what ports below 1024. I am moving it to -hackers since the response in -security has been limited and it possibly involves issues related to a common interface similar to sysctl. The code to implement the functionality is quite trivial; I put together a proof of concept implementation in 10 minutes which lets you set the uid which can bind to a select number of ports <1024 via sysctl. It is easy to expand this approach to the full range of ports under 1024 and have each port as a seperate sysctl variable, but that is ugly both in the design (ie. far too many silly defines, etc.) and in functionality (eg. sysctl output with a huge sysctl MIB). So, the questions are: - is this feature useful? If so, useful enough to be a patch, or useful enough to be included in the main source tree (hidden behind ifdefs to save the overhead unless people want it?)? I'm not so sure it is useful in most situations, but in some it could be. - any ideas for a good interface to it? While what Mark suggests below is quite possible, I have some doubts as to if it makes much sense to have a billion little programs each doing their own little thing. Ideally, there would be lots of other things that have similar requirements. Is a sysctl replacement appropriate? Is a large modification to sysctl appropriate? I think everyone agrees that it is a good thing to add to the various levels of privileges between a normal user and root. Are there any worthwhile standards (not just examples) to look at? Is there any reason to expect that anyone will ever take the effort to implement more full-featured ACLs for various subsystems in FreeBSD? How worthwhile is such an effort if done in little bits here and there, adding parts but probably never addressing some of the central issues? On Fri, 22 Nov 1996, Mark Newton wrote: > Peter Childs wrote: > > > Could an additional check in here just be used to check that if port > > requested is 25 and uid == mailmanager's uid then OK it? > > Only if everyone wanted to roll their own patch: There is no mail manager > uid on FreeBSD in the standard installation, and there's no reason to > think that everyone who added one would use the same id. > > That's certainly the right place to put any additional security mechanisms, > but I think we need one a bit more generic than that. I like the sysctl > idea, but it'd make sysctl -a unwieldy. > > There is another way, though: Consider nfs serving -- mountd reads > /etc/exports, parses its contents, fills in the relevent fields of a data > structure which describes which filesystems are to be exported, and pushes > that data structure into the kernel via a system call. Why not employ > a similar mechanism to read a config file which describes which users can > bind to which ports and syscalls it into the kernel to fulfil a task > similar to what the sysctl idea was attempting to acheive but without > the elephantine MIB? > > Just an idea... > > - mark > > --- > Mark Newton Email: newton@communica.com.au > Systems Engineer Phone: +61-8-8373-2523 > Communica Systems WWW: http://www.communica.com.au >