Re: cvs commit: src/usr.bin/make job.c

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

_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"