[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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. <ballombe@debian.org>

Imagine a large red swirl here. 


Reply to: