[Fedora-packaging] Re: buildroot race condition

[Enrico Scholz]

Axel.Thimm at ATrpms.net (Axel Thimm) writes:

> But this is all academic, try an attack and check the success rates,
> I'm sure they will be very low in the mktemp BuildRoot, 

I do not think that probabilities should be considered in security
related discussions; "A little bit insecure" is like "a little bit
pregnant" ;)

Attacker could start 100 of programs which are trying to exploit the
race. This has the effect of:

* increasing the load which in turn enlarges the timeslot for the race
* increasing the probability that the whole attack succeeds


Therefore: either let us fix this issue completely ('mkdir
$RPM_BUILD_ROOT'), perhaps with reducing functionality in some use cases
(e.g. %_tmpdir/%username/%name-... buildroot).

Moving the (secure) RPM_BUILD_ROOT initialization into the automatically
generated rpm script (afair, recent (jbj-)rpm does already 'rm -rf
$RPM_BUILD_ROOT' by default) should free packager from this task but
will require changes to all spec files.



Or, assume/require that %_tmpdir is at a secure location. I think,
nearly nobody reviews buildprocesses for security, but assumes that
they happen in a trusted environment. Builds itself have to happen as a
separate user; I do not want a broken Makefile which wipes my $HOME...


> even if you write the grep/sed stuff in C.

The 'mktemp(1) - rm(1)' sequence is done in the shell, which calls
dynamic linked binaries, which are doing lot of stuff before the first
'unlink(2)/rmdir(2)' is called.

In the meantime, attacker's C program has only to react on the inotify(7)
event (e.g. return from select(2)) and has to readdir(2) /var/tmp. I
think this is much faster than the 'mktemp(1) - rm(1)' sequence.



Enrico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20070314/0da2e4c0/attachment.sig>