Date: Wed, 18 May 2005 10:05:48 +0200 From: Alexander Leidinger <netchild@FreeBSD.org> To: Max Okumoto <okumoto@ucsd.edu> Cc: freebsd-security@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/make job.c Message-ID: <20050518100548.h8r4qc59c08swoog@netchild.homeip.net> In-Reply-To: <428A23A2.5080108@ucsd.edu> References: <200505121545.j4CFjENu078768@repoman.freebsd.org> <20050512180743.6z1h22fldwksgw4w@netchild.homeip.net> <hfbr7ge2gu.fsf@multivac.sdsc.edu> <42897003.2090005@ucsd.edu> <20050517144446.gibxprydoosokw0k@netchild.homeip.net> <428A23A2.5080108@ucsd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Max Okumoto <okumoto@ucsd.edu> wrote: [CC changed to freebsd-security instead of the cvs list] We're talking about replacing the home-grown mkfifo() funktion in make (a modified copy of mkstemp()) with mkdtemp() and creating the fifo in this new directory. Max worries about a possible race with this new approach. > Its not a race between two nice programs :-) The function mkdtmp() > creates a uniq directory, but make would then need to create a fifo > in it. (This is two steps, and thus can allow a race) > > Assume badmake has same uid, so it can create a file in the uniq > directory. (Of course this means that the bad guy already has > your account.) > Normal pattern: > --------------------- > make0: uses mkdtmp() to create dir /tmp/4321 > make0: tries to create fifo /tmp/4321 > make1: uses mkdtmp() to create dir /tmp/4321 but fails > make1: mkdtmp() next tries to create /tmp/4322 successs > make1: tries to create fifo /tmp/4322 > > > Sort of DOS: > --------------------- > make: uses mkdtmp() to create /tmp/1234/ > > badmake: watches for creation of /tmp/1234/ and > creates /tmp/1234/fifo. > > make: tries to create /tmp/1234/fifo fails. Right. But if your account is owned you have to worry about other things than a DOS of make (e.g. your ssh keys or access to your banking account or whatever). And there are more possibilities for a DOS in the case of an owned account (fork-bomb, allocating all memory, generating as much files as possible, ...; some of them can be limited with resource limits, but not all), so hardening make would be a nice goal, but in my opinion not a goal we need to persuade today since it wouldn't buy us much. But feel free to come up with some good arguments which I haven' thought of. Bye, Alexander. -- http://www.Leidinger.net/ Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org/ netchild @ FreeBSD.org : PGP ID = 72077137 Great acts are made up of small deeds. -- Lao Tsu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050518100548.h8r4qc59c08swoog>