Re: prelink performance gains

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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 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.

	- Panu -
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux