Date: Thu, 16 Aug 2001 00:08:23 -0700 From: "Crist J. Clark" <cristjc@earthlink.net> To: Robert Watson <rwatson@FreeBSD.org> Cc: David Malone <dwmalone@maths.tcd.ie>, Mikhail Teterin <mi@aldan.algebra.com>, alex@big.endian.de, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/etc inetd.conf Message-ID: <20010816000823.H330@blossom.cjclark.org> In-Reply-To: <Pine.NEB.3.96L.1010815125441.81642C-100000@fledge.watson.org>; from rwatson@FreeBSD.org on Wed, Aug 15, 2001 at 12:57:17PM -0400 References: <20010815123315.A35365@walton.maths.tcd.ie> <Pine.NEB.3.96L.1010815125441.81642C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 15, 2001 at 12:57:17PM -0400, Robert Watson wrote: > > On Wed, 15 Aug 2001, David Malone wrote: > > > On Tue, Aug 14, 2001 at 11:33:17PM -0400, Mikhail Teterin wrote: > > > On 14 Aug, Robert Watson wrote: > > > > All of these programs do involve risk, syslogd possibly a fair amount > > > > less so, and I'd be open to discussing how to disable them but > > > > minimize impact from an administrative standpoint. > > > > > > BTW, how hard is it to make syslogd run as nobody? Perhaps, > > > nobody:operator? Does it have to be root? > > > > It could possibly change to another uid after it had made it's sockets > > (port 514 and /var/run/log), connected to /dev/klog and opened all the > > log files. It would have to change back again if you HUPed it though. > > Note that if the same approach is taken as with ftpd, the ability to > exploit a bug resulting in arbitrary code execution can gain the > privilege. FTPd sets the effective euid to that of the user, but > maintains a saved uid so it can switch back to root to bind privileged > ports. An approach that might be taken is to have a pair of processes > -- one with privilege, and one without. The one with privilege would > communicate via IPC with the low privilege process, and grant specific > requests via file descriptor passing (such as the binding of sockets, > opening of devices, etc), limiting the scope of a vulnerability in the > exposed code. This does add substantial complexity, and has to be > carefully analyzed so as to determine that it won't leak privileges. We > have an on-going project as part of our DARPA grant to look at generate > techniques for partitioning applications this way. You can e-mail > Lee Badger <badger@tislabs.com> if you're interested -- he's a co-PI on > the project, and is focusing on the application impact of privilege. When are we just going to give up the now rather silly concept of "privileged ports?" Security on a UNIX platform gets _better_ when non-root processes can open ports <1024. Since no one (except for a limited few people on highly controlled, isolated networks) should ever trust remote machine, using a port <1024 is meaningless to the remote machine. It's also only an UNIX anachronism, and therefore meaningless in a heterogeneous environment. It would be so-o nice to have a sysctl(8) to turn off privileged ports and not have to worry about all of these problems with named(8), syslogd(8), ftpd(8), etc. If I do the work, is anyone going to fight committing it? -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010816000823.H330>