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

[markw at mohawksoft.com]

I kind of want to weigh in on a "meta" of this argument.

PATH is interesting but incomplete. One can always use a full path in an
unrestricted bash shell. If you use "rbash" the restricted version, PATH
is read-only and a user can not use absolute paths. There are, as always,
vulnerabilities every now and then but this helps prevent a class of
attack.

Lately I have become a big fan of the dreaded SELINUX system. If you
really want security, learn and enable SELINUX. Its a PITA, but it can
really help security in that all access is explicit.


> 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.
>
> _______________________________________________
> Discuss mailing list
> Discuss at lists.blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>