On Fri, 19 Dec 2014, Jonathan Nieder wrote: > >> 8.7 RUNPATH and RPATH > >> > >> Libraries and executables should not define RPATH or RUNPATH unless > >> absolutely necessary. > > This part seems vague to me --- if a project relies on RUNPATH but could > be modified to avoid relying on it, is today's use of RUNPATH absolutely > necessary? It's hard enough to act on this recommendation that I don't > think it belongs in policy yet.
IMO, it does belong in policy, and if anything, its inclusion is late for at least a decade. IMHO, the suggested wording does get the point across that whomever wants to use RPATH/RUNPATH must be prepared to defend its use with strong technical reasons. > >> Those that do should ensure that relative paths or paths that traverse > >> insecure directories (eg /tmp or /var/tmp) are not included. This > >> is to prevent an executable from loading a library from an untrusted > >> location. > > This part looks good. IMO, it is too weak. This is about introducing security hazards, so... "For security reasons, packages that set RPATH or RUNPATH MUST ensure that relative paths or paths that traverse insecure directories (e.g. /tmp or /var/tmp, their original build locations, user home directorites, etc) are not included. This is to prevent an executable from loading a library from an untrusted location." And in fact, I'd add: "Packages are not allowed to create *and* execute libraries or executables with unsafe RPATH or RUNPATH at any time, not even during their build process." -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
