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.