Bug#773557: debian-policy: Avoid unsafe RPATH/RUNPATH
On Sat, 2014-12-20 at 02:10 -0200, Henrique de Moraes Holschuh wrote: 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. Exactly. Without it I was concerned this would tacitly condone use of RPATH/RUNPATH and that's counterproductive. (At the same time there seem to be cases where complete avoidance is difficult hence the escape clause). This part looks good. IMO, it is too weak. This is about introducing security hazards, so... weak is a feature :) My suggested text is not perfect. My aim is to seed uncontroversial text that will educate, delimit bad practice, serve as a basis for further refinement. Perfect has been the enemy of good here. 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. But actually Package maintainers should not make or run dangerous stuff? Agreed -- and also seems uncontroversial. Although I think you mean or not and? Perhaps neither/nor to kill any ambiguity: 8.7 RUNPATH and RPATH Libraries and executables should not define RPATH or RUNPATH unless absolutely necessary. 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 should include the corner cases whereby the path list starts or ends with a colon, or includes two consecutive colons). Packages should neither create nor execute libraries or executables with unsafe RPATH or RUNPATH at any time, not even during their build process. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1419152328.4482.34.ca...@juliet.mcarpenter.org
Bug#773557: debian-policy: Avoid unsafe RPATH/RUNPATH
On Sun, 21 Dec 2014, Martin Carpenter wrote: 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. But actually Package maintainers should not make or run dangerous stuff? Agreed -- and also seems uncontroversial. Although I think you mean or not and? Perhaps neither/nor to kill any ambiguity: I did mean build a tool for its build using unsafe RPATH/RUNPATH, run that build tool, which is a common pitfall on crap that sets RPATH in the first place... If it builds the broken build-time tool, but never runs it, there is no harm since the unsafe binary is not going to be used or shipped. And if the unsafe binary is meant for manual running every so often by an attentive maintainer, we don't really care. 8.7 RUNPATH and RPATH Libraries and executables should not define RPATH or RUNPATH unless absolutely necessary. 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 should include the corner cases whereby the path list starts or ends with a colon, or includes two consecutive colons). Packages should neither create nor execute libraries or executables with unsafe RPATH or RUNPATH at any time, not even during their build process. This is a bit stronger than what I meant, but I don't have anything against this wording. -- 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 debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141221192648.gd30...@khazad-dum.debian.net
