Re: Why is "local" insecure PATH element ?

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

 



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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux