On Wed, Oct 16, 2013 at 7:57 AM, Panu Matilainen <pmatilai@xxxxxxxxxxxxxxx> 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@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/ ? > 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). > - Panu - > > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
