prelink should not mess with running executables

Brendan Jones brendan.jones.it at gmail.com
Thu Jul 19 23:04:43 UTC 2012


On 07/20/2012 12:57 AM, Sam Varshavchik wrote:
> Chris Adams writes:
>
>> Once upon a time, Sam Varshavchik <mrsam at courier-mta.com> said:
>> > If what prelink is doing is perfectly fine, then there's no reason
>> to have
>> > the /sbin/telinit hack in /etc/cron.daily, is it? That statement, of
>> > course,  would be either true or false irrespective of what I'm doing,
>> > which is  completely irrelevant.
>>
>> As others have pointed out, that's because init is NOT a standard daemon
>> (if you don't understand why PID 1 is special, I can't help you).
>
> No, it's not because init is "not a standard daemon". prelink did not
> single out init for special treatment just because of its special
> status. prelink does this to every binary, not just init. It's just that
> the results of prelink's frak-up are critical in init's case.
>
> The argument that prelink can only be an issue to daemons that continue
> to run past the shutdown system state is, of course, a specious
> argument. Just because other daemons get impacted by prelink's frak-up
> at other times, other than the system shut down, does not make the
> frak-up magically disappear with no side-effects, unfortunately.
>
> You are saying that the special-casing of init in prelink's wrapper is
> justified because without it, what prelink ends up doing to init will
> result in a crash. But, since there's no crash with anyone else, even
> though prelink does the exact same thing, that makes it ok.
>
> Which is, of course, an intellectually-bankrupt position to take.
>
> Either what prelink is doing is damaging and/or improper, or it's not.
> If what it does is hunky-dory, and has no ill effects, then there would
> be no need whatsoever for any special hacks, for any special
> executables, not-withstanding some other "standard" or "special" status
> they have.
>
>> You seem to be putting a lot of weight on the executable somebody ran to
>> access your program, over and above all the kernel facilities for
>> handling that (that are sufficient for everybody else, including heavily
>
> The only facilities that I'm aware of, and have been mentioned here, is
> inotify. I already said that I find the notion of having to inotify
> yourself, in order to mitigate prelink's bull-in-the-china shop behavior
> – and only prelink's – to be utterly preposterous.
>
> If inotify's the way to go here, then let's remove prelink's hack for
> init, and patch init to inotify itself, then. Sounds good to you?
>
> The inotify proposition reminds of Dan Bernstein's famous suggestion for
> distributing the officially blessed, binary-only qmail builds that have
> compiled-in userids, in a userid-independent way: if you want to
> distribute the officially blessed qmail build without a dependency on
> particular numeric uid values of qmail's reserved usernames, just
> provide a post-install hook that patches qmail's binaries with the uids
> in use on that particular server.
>
> Up to now, I never thought I'd ever come across another proposition
> that's just as mind-bending as that one.
>
> Well, looks like I was wrong.
>
>> security-minded folk like OpenBSD devs).  Aside from how a pathname is
>> not really a good indicator (see SELinux vs. AppArmor),
>
> Until someone explains how exec($pathname) results in two completely
> different binaries getting started (excepting prelink's brain damage,
> and, again, excluding other events that replace the binary, but which
> have easy ways to control, and mitigate), it looks like a pretty good
> indicator to me; except for, again, the breakage that results from
> prelink's unsolicited buggering.
>
>>                                                         how do you know
>> the binary hasn't been modified in place?  What good is your
>> super-special pathname security then?
>
> You are again trying to change the topic. How good or not good it is,
> this has no merits on prelink's behavior, and the fact that there's no
> way – aside from silly hacks involving inotify – to make prelink do what
> it does in a more organized, well-behaved, civilized fashion.
>
> And because you have no answer to that (and because once someone has
> root and can overwrite stuff in /usr/bin, all bets are off anyway, which
> you also ignore), you must then start attacking the dependency that
> brings it out, as a factor, instead of addressing it directly.
>
> There may or may not be an argument about the merits of using a pathname
> for authentication. This is fine, and that subject can be debated
> elsewhere. But, now you have a situation where prelink's design results
> in a binary whose raw content is different, but it's, for all practical
> purposes, is the same binary.
>
> But, because of the way that happens, it breaks daemons that rely on
> comparing /proc/[pid]/exe, which I assert is a valid mechanism for
> making that comparison. Now, that's not the end of the world, of course,
> and I found a very obvious way to work around it (without doing stupid
> things with inotify) a while ago, but just thought that it was
> worthwhile to discuss if what prelink is doing can be improved.
>
> But, apparently, this is impossible. Since it's not possible,
> apparently, to discuss prelink's flaws, the only response is to pretend
> that the problem must be elsewhere. You may or may think much of the
> benefits of comparing symlinks, but it is valid for it's documented and
> described purpose: the /proc/pid/exe symbolic link names the pathname of
> the binary that the process was started with. That's what it is. Except
> that it no longer is, as a result of prelink, and there is no convenient
> way to cooperate with prelink, to make it work, short of doing silly
> things with inotify. The fact that the same consequences can occur from
> upgrades, or some other unspecified events, is irrelevant, because
> appropriate measures /can/ be easily put in place, to take the
> appropriate action when upgrading, and most likely for whatever those
> other mysterious reasons might be. But this is not easily doable with
> prelink, without resorting to unwarranted nonsense, like inotify or
> similar workarounds.
>
> If someone's incapable of understanding this fundamental fact, I see
> nothing else that can be discussed that was not already covered in this
> thread.
>
>
>

Can someone please kill this thread.


More information about the devel mailing list