Bug#773557: debian-policy: Avoid unsafe RPATH/RUNPATH
On Fri, Dec 19, 2014 at 11:49:49PM +0100, Martin Carpenter wrote: Package: debian-policy Severity: important Tags: patch Dear Maintainer, The existing policy does not specify that the RPATH or RUNPATH (if present) should not contain relative paths or paths that traverse dangerous (eg world writable) directories. There is some discussion of this on the OSS-security list starting at: http://seclists.org/oss-sec/2014/q4/761 Example bugs that could be avoided with such a policy: https://bugs.debian.org/754278 https://bugs.debian.org/759868 Alas policy by itself does not prevent bugs, a lintian test is more efficient, (There is an existing check for RPATH in lintian (binary-or-shlib-defines-rpath) but it is only Certainty: possible due to possible caveats. Relative RPATH/RUNPATH on the other hand is slam-dunk certain). Then maybe lintian should have a separate test for relative RPATH/RUNPATH. There is some good discussion in these last two reports but they are both stale (5 years). I suspect that this is because the scope of these proposals is quite broad. Therefore I'd like to propose a (hopefully uncontraversial) paragraph that addresses at least the security concern and that may provide a base for further refinements in the spirit of #458824 and #555982 as well as a raison d'etre for a future lintian check to help avoid these security exposures. It is not necessary to document in policy all the obvious invalid behaviours of packages prior to have them check by lintian. 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). I would further suggest we forbid /usr/lib and /usr/lib/multiarch/, and only allow RUNPATH to other subdirectories of /usr/lib (to support what policy call plug-in). Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773557: debian-policy: Avoid unsafe RPATH/RUNPATH
Package: debian-policy Severity: important Tags: patch Dear Maintainer, The existing policy does not specify that the RPATH or RUNPATH (if present) should not contain relative paths or paths that traverse dangerous (eg world writable) directories. There is some discussion of this on the OSS-security list starting at: http://seclists.org/oss-sec/2014/q4/761 Example bugs that could be avoided with such a policy: https://bugs.debian.org/754278 https://bugs.debian.org/759868 See also: https://bugs.debian.org/458824 https://bugs.debian.org/555982 There is some good discussion in these last two reports but they are both stale (5 years). I suspect that this is because the scope of these proposals is quite broad. Therefore I'd like to propose a (hopefully uncontraversial) paragraph that addresses at least the security concern and that may provide a base for further refinements in the spirit of #458824 and #555982 as well as a raison d'etre for a future lintian check to help avoid these security exposures. (There is an existing check for RPATH in lintian (binary-or-shlib-defines-rpath) but it is only Certainty: possible due to possible caveats. Relative RPATH/RUNPATH on the other hand is slam-dunk certain). 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). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773557: debian-policy: Avoid unsafe RPATH/RUNPATH
Hi, Martin Carpenter 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. 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. (This should include the corner cases whereby the path list starts or ends with a colon, or includes two consecutive colons). Nit: s/This should include/This include/ Thanks and hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773557: debian-policy: Avoid unsafe RPATH/RUNPATH
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 debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
