cvs commit: src/usr.bin/make job.c
Alexander Leidinger
netchild at FreeBSD.org
Wed May 18 01:06:05 PDT 2005
Max Okumoto <okumoto at 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
More information about the freebsd-security
mailing list