prelink performance gains

[Panu Matilainen]

On 10/16/2013 10:17 AM, Dridi Boukelmoune wrote:
> On Wed, Oct 16, 2013 at 7:57 AM, Panu Matilainen
> <pmatilai at laiskiainen.org> wrote:
>> On 10/16/2013 12:51 AM, Dridi Boukelmoune wrote:
>>>
>>> Hi,
>>>
>>> This is one of these passionate threads I enjoy reading because I
>>> usually learn something interesting, and I also enjoy people being
>>> passionate about stuff. But this time I'm a bit disappointed about the
>>> defaults for Fedora.
>>>
>>> I'm a developer, and I work with production-like systems (and in some
>>> cases production systems) on my day job, so integrity of the system is
>>> something very important to me. I was startled when I first read that
>>> prelink touches binaries. For I'm too lazy to mount /usr as read-only
>>> (actually too lazy to mount it read/write for each yum upgrade), I
>>> naively expected binaries would be safe with default settings
>>> (assuming no attack).
>>>
>>> I've run the following commands:
>>>
>>> $ rpm -V varnish
>>> S.5....T.  c /etc/varnish/varnish.params
>>> $ rpm -V firefox
>>> $ rpm -V libreoffice-core
>>> prelink: /tmp/#prelink#.TZlaPL: Recorded 92 dependencies, now seeing -1
>>>
>>> S.?......    /usr/lib64/libreoffice/program/gengal.bin
>>> prelink: /tmp/#prelink#.3AZudQ: Recorded 87 dependencies, now seeing -1
>>>
>>> S.?......    /usr/lib64/libreoffice/program/libavmedialo.so
>>> prelink: /tmp/#prelink#.9xDUuT: Recorded 16 dependencies, now seeing -1
>>>
>>> S.?......    /usr/lib64/libreoffice/program/libbasegfxlo.so
>>> [...]
>>>
>>> Obviously, I'm ok with varnish being touched, I've changed something
>>> in the configuration. I'm also relieved that firefox's clean, because I
>>> use it heavily on a day-to-day basis. But this is rather disturbing to
>>> see prelink on rpm's output. Does it mean that rpm *itself* has been
>>> touched by prelink ? This sounds critical to me, how can I know that
>>> my rpmdb hasn't been corrupted ?
>>
>>
>> Yup, prelink screws up rpm -V pretty badly. Rpm does do know about prelink
>> and does 'prelink -u' to verify the unprelinked binary matches the original
>> digest but all too often prelink -u fails, in which case there's nothing rpm
>> can do about it. As in the above cases and perhaps the more common one:
>>
>> [root at localhost ~]# rpm -Va
>> prelink: /usr/lib/udev/udev-configure-printer: at least one of file's
>> dependencies has changed since prelinking
>> S.?......    /usr/lib/udev/udev-configure-printer
>> .M.......    /var/lib/nfs/rpc_pipefs
>> .M.......    /var/log/journal
>> prelink: /usr/bin/eog: at least one of file's dependencies has changed since
>> prelinking
>> S.?......    /usr/bin/eog
>> [...]
>>
>> This might not be *that* much of an issue on a more stable distro, but given
>> the constant churn of Fedora there's not a day when something hasn't
>> changed, causing rpm -Va (and other security tools) to come up with
>> indeterminate results until the prelink cronjob runs. And then more stuff
>> gets updated etc...
>>
>>
>>> Of course an attacker that would gain root access to the system could
>>> probably alter the rpmdb to "hide" what changed on the filesystem, but
>>> that's not my point.
>>
>>
>> Silently changing rpmdb to match what changed on the filesystem is that easy
>
> s/is/isn't/ ?

Whoops, indeed :)

>
>> as the file digests are buried within headers guarded with digital
>> signatures and further digests over the contents. You basically need to
>> replace the entire package, at which point it will no longer have a Fedora
>> signature and is quite a clear indication that something is not right.
>
> I said probably because I didn't know. I'd assume a tight security on
> such a critical package. But I have to confess I don't check that all
> my packages are signed that often. And rpm -V doesn't warn me about
> home-made packages not being signed. So a package losing its signature
> in the database could easily stay unnoticed (unless there are other
> mechanisms).

Yup, there are plenty of shortcomings in this area, rpm doesn't make it 
particularly easy (much less automated) to notice such issues. Such 
change does leave a detectable trace however so its *possible* to notice.

	- Panu -