Alan Coopersmith wrote:
>
> Hemantha Holla wrote:
>> Alan Coopersmith wrote:
>>> (though you need to be cleaning
>>> either LD_LIBRARY_PATH variant from the environment you use to
>>> fork/exec()
>>> other processes, so you don't break existing gnome apps if you call them
>>> as external file viewer helpers).
>> Since this env variable will be only set, instead of being exported, any
>> spawned processes will not be poisoned with the private libraries.
>
> If it's not exported, it won't even affect the Firefox binary, so that
> doesn't make sense.
I am sorry; I misunderstood launching Firefox like this
LD_LIBRARY_PATH_32=/usr/lib/gnome-private/lib "$prog" ${1+"$@"}
to mean that LD_LIBRARY_PATH_32 is only set and not exported.
Actually LD_LIBRARY_PATH* needn't be set to run Firefox. Since RUNPATH
is set to /usr/lib/gnome-private/lib while building Firefox and the
newer GNOME components, Firefox will pick up the new versions even
without setting LD_LIBRARY_PATH.
So instead of setting LD_LIBRARY_PATH, will unsetting it if user has
already set it, be enough to prevent this attack ? In this case (of
unsetting LD_LIBRARY_PATH), when plugins linked with older library
versions in /usr/lib are loaded (e.g. flash player plugin), there will
be 2 versions of the same library in memory.
Setting LD_LIBRARY_PATH and then clearing it when launching external
applications will need some modifications to Firefox code and none of us
in the team have looked into that yet.
>
>>> The following list seem like things needed to build firefox, but which
>>> don't need to be shipped to users of firefox - is there some reason
>>> these are needed, or is it just an artifact of the spec-files build
>>> system? (Though it would seem easy enough to just not deliver the
>>> -devel packages for private components to the WOS.)
>> Some other teams have requested availability of some of the newer
>> libraries through contracts. These files will allow those teams to link
>> to the newer versions easily. If there is some other formal way in which
>> these can be made available to those teams, there is no need to ship the
>> -devel packages.
>
> You can deliver the -devel packages to those teams without delivering them
> to all customers, or you can deliver them to the WOS and accept that
> customers may see them and try using them. (The -private in the directory
> name should be a strong clue that they shouldn't expect support for them.)
We'll deliver them to WOS. As you pointed out, while customers are free
to use
them, they can't expect support.
