On 10/16/2013 10:17 AM, Dridi Boukelmoune wrote:
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/ ?
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 -
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
