On Mon, Jul 16, 2012 at 4:20 AM, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> wrote:
> Chris Adams writes:
>
>> Once upon a time, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> said:
>> > Chris Adams writes:
>> > >Is there anything that actually does that and depends on the result?
>>
>> You skipped this part. Can you name something that tries this? I bet
>> somebody can break it if so.
>
> When the code is ready, I'll name it, certainly, and I'll welcome anyone to
> attempt to break it. But that's just a sideshow. Whether something like this
> can or cannot be broken does not make what prelink does any more or less
> sensible.
What prelink does in this respect is perfectly sensible. Being able
to rename() over an executable that is running is a long-standing UNIX
tradition, and prelink is only one of the manifestations of this.
As for the code authenticating via /proc/*/exe, _that's_ definitely
contrary to the UNIX model. The race conditions have been already
mentioned, and they are a real concern - things like this have been
exploited in the past - but ultimately they are a side issue. The
primary concern is that UNIX just nowhere, never, authenticates
executables - it authenticates identities attached to _running_
processes (UID, EUID, SELinux labels), it _never_ looks at the
executable file after execve() happens. In particular, what good is
it to know that a process was started by running $a_specific_inode,
when the process might be under control of a ptracing parent, and
might currently be executing a completely different code not present
in that inode at all?
> I think that 99% of the problems that prelink is creating can be easily
> avoided simply by having prelink automatically skip executables that are
> currently running.
That would break prelink:
1) prelink would not prelink the most important executables, mostly
defeating its purpose.
2) The regular prelink run re-randomizes the whole system, assigning
non-conflicting addresses; without the ability to update all
executables, some of the addresses would conflict and require run-time
relocation, again defeating the purpose of prelink.
Mirek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
