FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 09-02-2008, 08:01 AM
"Richard W.M. Jones"
 
Default wtf ... Something strips installed binaries???

I installed a binary from an RPM last night. Here's what I installed:

# rpm -qlvp ~rjones/rpmbuild/RPMS/i386/ocsigen-1.1.0-3.fc10.i386.rpm | grep /usr/bin
-rwxr-xr-x 1 root root 2294198 Sep 1 23:32 /usr/bin/ocsigen

This morning:

# ll /usr/bin/ocsigen
-rwxr-xr-x 1 root root 298908 2008-09-01 23:32 /usr/bin/ocsigen

This stipped binary is broken -- these binaries must NEVER be stripped!

/var/log/prelink/prelink.log shows that prelink did something to the
binary, but shows no errors.

(1) What is stripping installed binaries?

(2) How do I tell automated cron jobs NOT to interfere with installed
binaries?

Rich.

PS. Personally I think the idea of having cronjobs which modify system
files under /usr in-place is totally crack. If prelinking is
genuinely useful, save the extra prelink data into a /var file.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 09-02-2008, 09:01 AM
Thomas M Steenholdt
 
Default wtf ... Something strips installed binaries???

Richard W.M. Jones wrote:

I installed a binary from an RPM last night. Here's what I installed:

# rpm -qlvp ~rjones/rpmbuild/RPMS/i386/ocsigen-1.1.0-3.fc10.i386.rpm | grep /usr/bin
-rwxr-xr-x 1 root root 2294198 Sep 1 23:32 /usr/bin/ocsigen

This morning:

# ll /usr/bin/ocsigen
-rwxr-xr-x 1 root root 298908 2008-09-01 23:32 /usr/bin/ocsigen


This stipped binary is broken -- these binaries must NEVER be stripped!

/var/log/prelink/prelink.log shows that prelink did something to the
binary, but shows no errors.

(1) What is stripping installed binaries?

(2) How do I tell automated cron jobs NOT to interfere with installed
binaries?

Rich.

PS. Personally I think the idea of having cronjobs which modify system
files under /usr in-place is totally crack. If prelinking is
genuinely useful, save the extra prelink data into a /var file.



I wasn't even aware that prelinking actually changed the files. Isn't
this kind of dangerous from a system-integrity point-of-view. How can we
ever validate binaries if they are modified on purpose?


/Thomas

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 09-02-2008, 09:03 AM
"Mary Ellen Foster"
 
Default wtf ... Something strips installed binaries???

2008/9/2 Richard W.M. Jones <rjones@redhat.com>:
> (2) How do I tell automated cron jobs NOT to interfere with installed
> binaries?

I can't comment on the other issues, but for this question, you
probably want to drop a file into /etc/prelink.conf.d to "blacklist"
the files you don't need prelinked. Based on the example that's there
(nss-prelink.conf), you want to include lines like this:
-b /pattern/that/matches/file*

I once had a program that stopped working after prelink ran, but
that's just because it checked its own md5sum and then "called home"
to see if there was a newer version available. I've never seen it
actually break anything about the executable itself.

MEF

--
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universität München
and ICCS, School of Informatics, University of Edinburgh

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 09-02-2008, 09:05 AM
"Bill Crawford"
 
Default wtf ... Something strips installed binaries???

Thomas M Steenholdt wrote:
> I wasn't even aware that prelinking actually changed the files. Isn't this kind of dangerous from a system-integrity point-of-view. How can we ever validate binaries if they are modified on purpose?

With "prelink --verify" ?

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 09-02-2008, 09:26 AM
Ralf Corsepius
 
Default wtf ... Something strips installed binaries???

On Tue, 2008-09-02 at 09:01 +0100, Richard W.M. Jones wrote:
> I installed a binary from an RPM last night. Here's what I installed:
>
> # rpm -qlvp ~rjones/rpmbuild/RPMS/i386/ocsigen-1.1.0-3.fc10.i386.rpm | grep /usr/bin
> -rwxr-xr-x 1 root root 2294198 Sep 1 23:32 /usr/bin/ocsigen
>
> This morning:
>
> # ll /usr/bin/ocsigen
> -rwxr-xr-x 1 root root 298908 2008-09-01 23:32 /usr/bin/ocsigen
>
> This stipped binary is broken -- these binaries must NEVER be stripped!
Why? I for one consider applications which "must NEVER be stripped" to
be "broken".

> PS. Personally I think the idea of having cronjobs which modify system
> files under /usr in-place is totally crack.
Agreed.

Ralf


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 09-02-2008, 09:48 AM
"Daniel P. Berrange"
 
Default wtf ... Something strips installed binaries???

On Tue, Sep 02, 2008 at 09:01:50AM +0100, Richard W.M. Jones wrote:
>
> I installed a binary from an RPM last night. Here's what I installed:
>
> # rpm -qlvp ~rjones/rpmbuild/RPMS/i386/ocsigen-1.1.0-3.fc10.i386.rpm | grep /usr/bin
> -rwxr-xr-x 1 root root 2294198 Sep 1 23:32 /usr/bin/ocsigen
>
> This morning:
>
> # ll /usr/bin/ocsigen
> -rwxr-xr-x 1 root root 298908 2008-09-01 23:32 /usr/bin/ocsigen
>
> This stipped binary is broken -- these binaries must NEVER be stripped!

Why mustn't it be stripped ? If it genuinely needs the symbol data, then
adding the blacklist to prelink is reasonable. If it is merely that the
strip binary is doing something wrong, then a BZ against strip is needed
to get it fixed.

Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 09-02-2008, 09:57 AM
"Richard W.M. Jones"
 
Default wtf ... Something strips installed binaries???

On Tue, Sep 02, 2008 at 10:48:55AM +0100, Daniel P. Berrange wrote:
> On Tue, Sep 02, 2008 at 09:01:50AM +0100, Richard W.M. Jones wrote:
> >
> > I installed a binary from an RPM last night. Here's what I installed:
> >
> > # rpm -qlvp ~rjones/rpmbuild/RPMS/i386/ocsigen-1.1.0-3.fc10.i386.rpm | grep /usr/bin
> > -rwxr-xr-x 1 root root 2294198 Sep 1 23:32 /usr/bin/ocsigen
> >
> > This morning:
> >
> > # ll /usr/bin/ocsigen
> > -rwxr-xr-x 1 root root 298908 2008-09-01 23:32 /usr/bin/ocsigen
> >
> > This stipped binary is broken -- these binaries must NEVER be stripped!
>
> Why mustn't it be stripped ? If it genuinely needs the symbol data, then
> adding the blacklist to prelink is reasonable. If it is merely that the
> strip binary is doing something wrong, then a BZ against strip is needed
> to get it fixed.

Apparently it's because it appends bytecode to its own binary (which
is a broken thing to do, but is now deprecated anyway[1]). Strip on
the other hand ought to recognise that the binary is no longer a
coherent ELF file and quit. So I'd agree this is really a bug against
strip.

Note that we found that strip also destroys MinGW (Windows) binaries.
Again, it should give up on binaries that it doesn't understand,
rather than destroying them.

But is it /usr/bin/strip? Does prelink run /usr/bin/strip first? Do
prelink and strip use a common ELF-manipulation library which is at
fault?

Really, cronjobs shouldn't be modifying files in /usr/bin. Save data
in /var/, or modify the ELF format to make it more efficient so it
doesn't need prelink.

Rich.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256900#49

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 09-02-2008, 12:41 PM
Bruno Wolff III
 
Default wtf ... Something strips installed binaries???

On Tue, Sep 02, 2008 at 07:01:43 -0200,
Thomas M Steenholdt <tmus@tmus.dk> wrote:
>
> I wasn't even aware that prelinking actually changed the files. Isn't
> this kind of dangerous from a system-integrity point-of-view. How can we
> ever validate binaries if they are modified on purpose?

I run rpmverify to check installed files and it seems to handle prelinked
files reasonably. I don't know what it does to check them, but it does
appear to be able to.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 09-02-2008, 01:07 PM
Thomas M Steenholdt
 
Default wtf ... Something strips installed binaries???

Bill Crawford wrote:

Thomas M Steenholdt wrote:

I wasn't even aware that prelinking actually changed the files. Isn't this kind of dangerous from a system-integrity point-of-view. How can we ever validate binaries if they are modified on purpose?


With "prelink --verify" ?



I can't see how that would actually verify that the binary has not been
modified by a rootkit or whatever? rpm -V should be able to detect this,
on the other hand, but how it works in conjunction with prelinking I
don't know...


/Thomas

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 09-02-2008, 01:16 PM
"Daniel P. Berrange"
 
Default wtf ... Something strips installed binaries???

On Tue, Sep 02, 2008 at 11:07:45AM -0200, Thomas M Steenholdt wrote:
> Bill Crawford wrote:
> >Thomas M Steenholdt wrote:
> >>I wasn't even aware that prelinking actually changed the files. Isn't
> >>this kind of dangerous from a system-integrity point-of-view. How can we
> >>ever validate binaries if they are modified on purpose?
> >
> >With "prelink --verify" ?
> >
>
> I can't see how that would actually verify that the binary has not been
> modified by a rootkit or whatever?

It is explained in the manpage for prelink

-y --verify
Verifies a prelinked binary or library. This
option can be used only on a single binary or
library. It first applies an --undo operation on
the file, then prelinks just that file again and
compares this with the original file. If both are
identical, it prints the file after --undo opera-
tion on standard output and exits with zero sta-
tus. Otherwise it exits with error status. Thus
if --verify operation returns zero exit status
and its standard output is equal to the content
of the binary or library before prelinking, you
can be sure that nobody modified the binaries or
libraries after prelinking. Similarly with mes-
sage digests and checksums (unless you trigger
the improbable case of modified file and original
file having the same digest or checksum).

> rpm -V should be able to detect this,
> on the other hand, but how it works in conjunction with prelinking I
> don't know...

IIRC, rpm -V is prelink aware, and calls out to prelink --verify rather than
doing a blind checksum compare.

Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 07:09 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org