Why is "local" insecure PATH element ?

[Lukas Czerner]

Hi,

I've noticed some failures in automated tests in bodhi, specifically
this one:

    {
       "arch" : "x86_64",
       "code" : "SuspiciousPath",
       "context" : {
	  "excerpt" : [
	     "PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
	  ],
	  "path" : "/usr/sbin/e2scrub"
       },
       "diag" : "Potentially insecure PATH element
<tt>/local</tt>",
       "subpackage" : "e2scrub"
    },


I am not sure why it's considered insecure while on all of the Fedora
and RHEL systems I have available "/usr/local/sbin:/usr/local/bin" is a
default part of the PATH.

What am I missing ?

-Lukas

[Samuel Sieb]

On 4/1/20 4:27 AM, Lukas Czerner wrote:
>  I've noticed some failures in automated tests in bodhi,
> specifically
>  this one:
>  
>       {
>          "arch" : "x86_64",
>          "code" : "SuspiciousPath",
>          "context" : {
>  	  "excerpt" : [
>  	     "PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
>  	  ],
>  	  "path" : "/usr/sbin/e2scrub"
>          },
>          "diag" : "Potentially insecure PATH element
> <tt>/local</tt>",
>          "subpackage" : "e2scrub"
>       },
>  
>  I am not sure why it's considered insecure while on all of the Fedora
>  and RHEL systems I have available "/usr/local/sbin:/usr/local/bin" is a
>  default part of the PATH. 
You don't want a system script to be looking for executables in 
/usr/local before the regular bin directories.  And it's probably better 
that it doesn't look in /usr/local at all.
It's fine for the admin to put extra things in /usr/local, but those 
paths don't override the system ones.

[Lukas Czerner]

On Wed, Apr 01, 2020 at 11:26:04AM -0700, Samuel Sieb wrote:
>  On 4/1/20 4:27 AM, Lukas Czerner wrote:
>  > I've noticed some failures in automated tests in bodhi, specifically
>  > this one:
>  > 
>  >      {
>  >         "arch" : "x86_64",
>  >         "code" : "SuspiciousPath",
>  >         "context" : {
>  > 	  "excerpt" : [
>  > 	     "PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
>  > 	  ],
>  > 	  "path" : "/usr/sbin/e2scrub"
>  >         },
>  >         "diag" : "Potentially insecure PATH element
> <tt>/local</tt>",
>  >         "subpackage" : "e2scrub"
>  >      },
>  > 
>  > I am not sure why it's considered insecure while on all of the Fedora
>  > and RHEL systems I have available "/usr/local/sbin:/usr/local/bin" is a
>  > default part of the PATH.
>  
>  You don't want a system script to be looking for executables in /usr/local
>  before the regular bin directories.  And it's probably better that it
>  doesn't look in /usr/local at all.
>  It's fine for the admin to put extra things in /usr/local, but those paths
>  don't override the system ones. 
Thanks, that's understandable, but then why the PATH on my system is

/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin

or

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin

all the systems I try include /usr/local in the PATH.

-Lukas

>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Stephen Gallagher]

On Wed, Apr 1, 2020 at 3:58 PM Lukas Czerner <lczerner(a)redhat.com&gt; wrote:
>  On Wed, Apr 01, 2020 at 11:26:04AM -0700, Samuel Sieb wrote:
>  > On 4/1/20 4:27 AM, Lukas Czerner wrote:
>  > > I've noticed some failures in automated tests in bodhi, specifically
>  > > this one:
>  > >
>  > >      {
>  > >         "arch" : "x86_64",
>  > >         "code" : "SuspiciousPath",
>  > >         "context" : {
>  > >       "excerpt" : [
>  > >         
> "PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
>  > >       ],
>  > >       "path" : "/usr/sbin/e2scrub"
>  > >         },
>  > >         "diag" : "Potentially insecure PATH element
> <tt>/local</tt>",
>  > >         "subpackage" : "e2scrub"
>  > >      },
>  > >
>  > > I am not sure why it's considered insecure while on all of the Fedora
>  > > and RHEL systems I have available "/usr/local/sbin:/usr/local/bin" is
> a
>  > > default part of the PATH.
>  >
>  > You don't want a system script to be looking for executables in /usr/local
>  > before the regular bin directories.  And it's probably better that it
>  > doesn't look in /usr/local at all.
>  > It's fine for the admin to put extra things in /usr/local, but those paths
>  > don't override the system ones.
>
>  Thanks, that's understandable, but then why the PATH on my system is
>
>  /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
>
>  or
>
>  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
>
>  all the systems I try include /usr/local in the PATH.
>  
We don't want anything installed via RPM to be using /usr/local
directly. The /usr/local path is intended for locally-installed
content by the administrator, while /usr is meant for content coming
from the distributor.

For example, I maintain the `npm` package. It installs its binary as
/usr/bin/npm.  However, if I use npm (it's a Node.js package manager)
to install a Node-based binary with `npm -g install someapp`, it will
install it in /usr/local rather than /usr. This is done in part to
avoid future conflicts where RPM might try to overwrite
locally-installed content or where a tool like `npm` is overwriting
RPM-managed content (which it was doing until fairly recently...)

[Lukas Czerner]

On Wed, Apr 01, 2020 at 04:10:02PM -0400, Stephen Gallagher wrote:
>  On Wed, Apr 1, 2020 at 3:58 PM Lukas Czerner
> <lczerner(a)redhat.com&gt; wrote:
>  >
>  > On Wed, Apr 01, 2020 at 11:26:04AM -0700, Samuel Sieb wrote:
>  > > On 4/1/20 4:27 AM, Lukas Czerner wrote:
>  > > > I've noticed some failures in automated tests in bodhi, specifically
>  > > > this one:
>  > > >
>  > > >      {
>  > > >         "arch" : "x86_64",
>  > > >         "code" : "SuspiciousPath",
>  > > >         "context" : {
>  > > >       "excerpt" : [
>  > > >         
> "PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
>  > > >       ],
>  > > >       "path" : "/usr/sbin/e2scrub"
>  > > >         },
>  > > >         "diag" : "Potentially insecure PATH element
> <tt>/local</tt>",
>  > > >         "subpackage" : "e2scrub"
>  > > >      },
>  > > >
>  > > > I am not sure why it's considered insecure while on all of the Fedora
>  > > > and RHEL systems I have available
> "/usr/local/sbin:/usr/local/bin" is a
>  > > > default part of the PATH.
>  > >
>  > > You don't want a system script to be looking for executables in /usr/local
>  > > before the regular bin directories.  And it's probably better that it
>  > > doesn't look in /usr/local at all.
>  > > It's fine for the admin to put extra things in /usr/local, but those paths
>  > > don't override the system ones.
>  >
>  > Thanks, that's understandable, but then why the PATH on my system is
>  >
>  > /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
>  >
>  > or
>  >
>  > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
>  >
>  > all the systems I try include /usr/local in the PATH.
>  >
>  
>  We don't want anything installed via RPM to be using /usr/local
>  directly. The /usr/local path is intended for locally-installed
>  content by the administrator, while /usr is meant for content coming
>  from the distributor.
>  
>  For example, I maintain the `npm` package. It installs its binary as
>  /usr/bin/npm.  However, if I use npm (it's a Node.js package manager)
>  to install a Node-based binary with `npm -g install someapp`, it will
>  install it in /usr/local rather than /usr. This is done in part to
>  avoid future conflicts where RPM might try to overwrite
>  locally-installed content or where a tool like `npm` is overwriting
>  RPM-managed content (which it was doing until fairly recently...) 
Thanks I appreciate the explanation, but I am aware of this. What I am
trying to understand is how setting a PATH with "/local" element from a
script is insecure. When I run the scrip on my system the PATH already
include the "/local" element by default so it's not really changing
anything. Right ?

Is it that the test is using the fact that we set the PATH with "/local"
element as an indication that it's going to put something there ? It's
not the case here and in fact I think that the line should be removed
from the script, but that's besides the point. I am trying to undestand
why the test is failing and what is it protecting from.

Anyone has any idea where to find the person who is responsible for
those automated tests ?

-Lukas

>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 01, 2020 at 09:57:25PM +0200, Lukas Czerner wrote:
>  On Wed, Apr 01, 2020 at 11:26:04AM -0700, Samuel Sieb wrote:
>  > On 4/1/20 4:27 AM, Lukas Czerner wrote:
>  > > I've noticed some failures in automated tests in bodhi, specifically
>  > > this one:
>  > > 
>  > >      {
>  > >         "arch" : "x86_64",
>  > >         "code" : "SuspiciousPath",
>  > >         "context" : {
>  > > 	  "excerpt" : [
>  > > 	    
> "PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
>  > > 	  ],
>  > > 	  "path" : "/usr/sbin/e2scrub"
>  > >         },
>  > >         "diag" : "Potentially insecure PATH element
> <tt>/local</tt>",
>  > >         "subpackage" : "e2scrub"
>  > >      },
>  > > 
>  > > I am not sure why it's considered insecure while on all of the Fedora
>  > > and RHEL systems I have available "/usr/local/sbin:/usr/local/bin" is
> a
>  > > default part of the PATH.
>  > 
>  > You don't want a system script to be looking for executables in /usr/local
>  > before the regular bin directories.  And it's probably better that it
>  > doesn't look in /usr/local at all.
>  > It's fine for the admin to put extra things in /usr/local, but those paths
>  > don't override the system ones.
>  
>  Thanks, that's understandable, but then why the PATH on my system is
>  
>  /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
>  
>  or
>  
>  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
>  
>  all the systems I try include /usr/local in the PATH. 
Yes. And in fact, most of packaged software that uses calls other
binaries will use $PATH to find the appropriate binary, so taking care
to just limit the first "step", i.e. call the first binary by full
path is generally pointless.

There was this pattern in rpm packaging to call utilities with
full path, e.g. %__make which expands to /usr/bin/make, completely
ignoring the fact that make will immediately fork other binaries,
also including make!, using $PATH.

For the systemd package, this warning is emitted because systemd uses
a path including /usr/local to look for executables. systemd looks for
*units* in /usr/local/lib/systemd/system, so it only seems natural to
look for executables mentioned in those units also in
/usr/local/{sbin,bin}.

Overall, I think this warning is severely misguided. In general, for
_most_ packaged software it is appropriate and expected to use $PATH,
to allow administrators to enhance and replace parts of the system
with local binaries. For specific packages that don't do that, a full
audit would need to be done that they always use a full path or
$SANITIZE path, and just a cursory check for embedded strings is
meaningless.

Zbyszek