[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 07:43:31PM -0400, Rich Pieri wrote:
> On Wed, 21 Jun 2023 19:26:55 -0400
> Dan Ritter <dsr at randomstring.org> wrote:
> 
> > If you're packaging for a particular distro, you know where they
> > put it.
> 
> For systems that implement merged /usr you just use /usr/bin/perl. For
> systems with optional merged /usr then your post-install scripts will
> need to adjust the interpreter line appropriately to match the OS.
> 
> #!/usr/bin/env perl is often used but it is not secure, and I advise
> against it.

I agree with all of this, but there's some nuance.

1. As I indicated in the other message, if the program is intended to
   run exclusively in the security context of the user running it, and
   does not at any point require elevated privileges (which needs to
   be evaluated carefully), then using /usr/bin/env is PROBABLY fine,
   particularly if you wrote it and know what it does.

   BUT: the onus is on the user running the perl script to make sure
   it has nothing malicious in it that aims to attack the user running
   it, and/or that their PATH is carefully crafted to avoid this
   problem. [This mostly means putting safe system paths first before
   any custom paths, but there may be additional nuance particular to
   your environment.]   Attacking non-root users is somewhat atypical
   of attacks--most seek to gain privilege escalation rather than
   target users--but it certainly can be done, and sometimes attacking
   a user can be a route to gaining more privileges.  Caveat emptor.
   Avoid when you have a workable alternative.

2. Whether or not you have merged, perl may not be installed in either
   /bin or /usr/bin (it should never really be in /bin anyway).  
   
   2a. IMO, it should be safe in your environment to invoke it as
       /usr/bin/perl regardless of where it is, so if it isn't there,
       you (or your sysadmin) should probably install a symlink or
       shell wrapper that invokes the real perl.  It's usually easier
       to just install it in /usr/bin.  If you need multiple versions
       of perl there could be a conflict, but it's at least an option.
       
   2b. If your environment is homogenous and perl is always installed
       in the same place, regardless of where it is, just put that
       path in your #! line.  If your environment changes, or if you
       change environments, and you have a bunch of these to deal
       with, you can generally fix the path of all of them quickly and
       easily with a shell one-liner, so long as you have them stored
       all in roughly one place.  Be sure to have back-ups, as always!

-- 
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.