Date: Tue, 17 Nov 1998 00:19:36 -0800 (PST) From: Cliff Skolnick <cliff@steam.com> To: Andrew McNaughton <andrew@squiz.co.nz> Cc: Matthew Dillon <dillon@apollo.backplane.com>, William McVey <wam@sa.fedex.com>, Warner Losh <imp@village.org>, Andre Albsmeier <andre.albsmeier@mchp.siemens.de>, freebsd-security@FreeBSD.ORG, "Jordan K. Hubbard" <jkh@zippy.cdrom.com>, Dima Ruban <dima@best.net> Subject: Re: Would this make FreeBSD more secure? & sendmail changes in OpenBSD 2.4 Message-ID: <Pine.BSF.4.05.9811162354100.26690-100000@lazlo.steam.com> In-Reply-To: <Pine.BSF.4.01.9811171958170.8181-100000@aniwa.sky>
next in thread | previous in thread | raw e-mail | index | archive | help
Adding the ability for non-root UID to access ports is a fundamental change in the "standard UNIX way." The standard UNIX way to being how a number of books explain to the novice systems programmer how to do it. I do agree that the problem is real, but as a developer who wants a broad audience consisting of all UNIX systems I will not use the FreeBSD specific feature. Now we can argue that any security bug will be less harmful, but I also wonder how harmful a day or week delay while a ports update is made can be. But I will not only complain, here are a couple ideas. Of course there is a set of programs like identd and talk where this is really not a problem since inetd open the socket and can just pass it down the chain after setuid to some user with barely enough privileges to access the needed resources. This is pretty straight forward, and many of us have already done this. I am more concerned about stand alone daemons like sendmail, syslog, apache, etc. A well written program could simply have a setuid wrapper like innd that opens the socket, does a setuid() to some other user, then exec()s the real program. If I do this I know my program will work on most UNIX boxes in a reasonably secure way. Now if someone wanted to write a wrapper to make this easy, and it ran on most if not all UNIX systems great. The program would be setuid root, open a port (restricted by some access file like the suggested /etc/bindports), and exec the daemon. Of course there would be some interface dealing with what file descriptors contained the socket, perhaps passed as a parameter. A number of enhancements pop into mind too. Perhaps a nice chroot option, resource limit control, and maybe nice could also be added. Come to think of it, this would be a nice program. Cliff On Tue, 17 Nov 1998, Andrew McNaughton wrote: > On Mon, 16 Nov 1998, Matthew Dillon wrote: > > > > :If we are adding standard ids to the password file, what do you think of > > :adding the following loginids and groupids for services that can run > > :standalone as unprivilged users (these are ones I've set up on my set of > > :machines, it'd be nice to "standardize" them): > > : smtp (uid and gid of 25) > > : www (uid and gid of 80) > > : ftp (uid and gid of 21) > > : tftp (uid and gid of 69) > > : syslog (uid and gid of 514) > > : (another root daemon which probably doesn't need root, I > > : just made the changes on one of my machines... I'll let the > > : list know how it works out.) > > > > I agree. Normally I'd use the same uid as the group id if a group > > exists, or barring that the /etc/services port (but those start to > > infringe on what people use for real user id's, we probably have to > > keep the id's < 100). > > I don't think it's going to be feasible to claim a large number of low > numbered gid's. It will clash with too many existing schemes. I can see > administrators less familiar with freebsd making mistakes with serious > consequences if they are not familiar with this scheme. The indirection > provided by named groups is useful here. How about having a file which > states which ports are allowed to which groups. eg have something like > /etc/bindports with a format like: > > smtp: 25 > www: 80, 8080 > ftp: 21 > tftp: 69 > syslog: 514 > bind: 1025-65335 # ???? > > The key before the colon gives the name of a group, which could have any > group number. The value after the colon gives a comma delimited list of > ports (possibly including ranges indicated by dash) to which members of > that group are allowed access. These lists are cumulative for all the > groups the processes EUID is a member of. > > As suggested by the last two line, this mechanism could be used (if > considered desirable) to limit access to high numbered ports also with a > group which most users are members of. Alternatively there could be a > nobind group which prohibits binding not specifically enabled by > membership of another group. I'm not sure whether there is any good > reason to do this, but I thought I'd put it in for discussion. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -- Cliff Skolnick Steam Tunnel Operations cliff@steam.com http://www.steam.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9811162354100.26690-100000>