[Discuss] Program path maintenance and security (was Re: Debian 12 vs. WSL 1)

[invalid at pizzashack.org (Derek Martin)]

On Wed, Jun 21, 2023 at 06:57:48PM -0400, Rich Pieri wrote:
> On Wed, 21 Jun 2023 11:35:08 -0500
> Derek Martin <invalid at pizzashack.org> wrote:
> 
> > I think it's worth expanding on this just a bit.  This IS good
> > practice, and you should do it in your shell scripts--particularly
> > when you need to execute system utilities but can't be sure in which
> > system path they will live--and you should probably also provide a
> > means for users to configure this in larger software projects where
> > you end up executing system commands on the user's behalf (and
> 
> The foundation of every best practice in security is implicit deny.

Yes, absolutely.  PATH *IS* implicit deny.  It denies searched
execution of binaries anywhere other than where you explicitly allow,
by setting PATH.  Doing this properly completely prevents execution of
insecure binaries via searching in paths not explicitly allowed.  In
that sense it is no less secure than specifying the full path.  The
only sense in which it is less secure is that it is potentially easier
to screw up, and NORMALLY under the user's control--EXCEPT when it is
baked into the program you are running.  So do that.

But that is exactly why the /usr/bin/env trick that Bill mentions IS
less secure--its scope is inherited from the user and takes effect
before the program starts its execution--it precedes the program's
ability to enforce a more secure path.  LD_LIBRARY_PATH and friends is
different from PATH for the same reason (and I think also because
people are generally less aware of it).  Once the program has begun
execution it's already too late for it to do anything about that.  IMO
it should be disabled by default for non-root users, with a way to
configre where and when it is allowed.  That may even be the
case--fortunately I am no longer in a position where I need to care
about those details. =8^)

Security is always about tradeoffs, and congrats, you found one.
Using full paths only can work when the same script will be run on
systems where binaries are always installed in the same place.  That
IS one solution to this problem (e.g. install perl in /usr/bin even if
you're installing from source, rather than using a package provided by
your OS vendor).  Merging /usr is effectively the same solution
(though it doesn't cover locally installed software, still).  You
already know this--it's one of the main points you made when I asked
the question in the other thread.

But if you can't do that, or if you or someone before you just did not
do that, using full paths simply won't work, so you need a different
solution.  You can redo what was done before you, but in my experience
that rarely happens, precisely because of what I was saying in the
other thread: The benefit doesn't outweigh the cost, because there are
cheaper alternatives, e.g. doing what I described.  If done properly
it's just as effective, and the cost of doing it (i.e. adding the
single line of code to your program required to do it, in most cases)
will take a very long time to catch up to the cost of completely
reorganizing your environment to deal with it.  It's also worth
pointing out that in most cases, programs meant to execute with the
user's own security context don't even need this--relying in path is
fine without jumping through hoops.  It generally only matters at all
if part of the tool chain needs elevated privileges.

Moreover, even if there were a significant difference in security,
practically speaking, which there isn't, there's no good reason you
couldn't do both, wherever full paths will work.  I stand by what I
said: Doing this is good practice.

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.