Date: Wed, 18 May 2005 01:41:12 -0700 From: Max Okumoto <okumoto@ucsd.edu> To: Alexander Leidinger <netchild@FreeBSD.org> Cc: freebsd-security@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/make job.c Message-ID: <hfacmt7wpj.fsf@multivac.sdsc.edu> In-Reply-To: <20050518100548.h8r4qc59c08swoog@netchild.homeip.net> (Alexander Leidinger's message of "Wed, 18 May 2005 10:05:48 %2B0200") 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> <20050518100548.h8r4qc59c08swoog@netchild.homeip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Leidinger <netchild@FreeBSD.org> writes:
> 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.
Yup, like I said, should I even be worried about this at all?
Your idea of using mkdtemp() can be fixed by putting a loop
around the code. Each time around the loop would be expensive
but we wouldn't be doing that to often anyway.
loop:
mkdtemp(template)
mkfifo(tempalte + "/fifo")
if error remove temp directory, restore template and loop.
Or better yet, if someone could create an equiv function in libc
so I don't have to maintain it in make(1) :-) Do any other
programs need the ability to make a temp fifo?
Personally, I don't think it is a risk, but I wanted other
peoples opinions, before I tried to fix a non-issue. :-)
Max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?hfacmt7wpj.fsf>