Date: Thu, 16 Aug 2001 11:50:55 +0300 From: Maxim Sobolev <sobomax@FreeBSD.org> To: cjclark@alum.mit.edu Cc: Robert Watson <rwatson@FreeBSD.ORG>, 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: <3B7B896F.F0F8F244@FreeBSD.org> References: <20010815123315.A35365@walton.maths.tcd.ie> <Pine.NEB.3.96L.1010815125441.81642C-100000@fledge.watson.org> <20010816000823.H330@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"Crist J. Clark" wrote: > 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? There is another problem with unprivileging ports below < 1024 - the local user potentialy may DOS service by binding to the same port when the service restarts (for example sysadmin restarts it by -HUP signal). I guess it should be relatively easy to write an exploit that constantly monitors whether specified port is binded or not and immediately binds to it once the port for some reason is free. -Maxim 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?3B7B896F.F0F8F244>