Axel.Thimm@xxxxxxxxxx (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
Attachment:
pgp8wbtNhxmqV.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
