Comment empêcher les scripts / commandes de détourner la capacité sudo en cache de votre session?

You can run

sudo -k

before you run your script. It will clear the cached credentials and the next sudo will ask again for your password.

Here's a way to do what you want (I think).

1. Move your sudo elsewhere:

   mv /usr/bin/sudo /usr/bin/sudo_real
   

2. Put the following into usr/bin/sudo:

   #!/bin/bash -i
   # Allows 'sudo' to be run with cached credentials from the command line,
   # but clears the cache if run from within a script.
   # Get the last command executed manually from the history
   LAST_COMMAND=`history | tail -n 1 | cut -c 8-`
   
   if [[ "${LAST_COMMAND}" == "sudo "* ]]; then
       # The last command was 'sudo' - i.e. the user ran sudo 
       sudo_real "[email protected]"
   else
       # The last command was NOT sudo - so this sudo was called from within a script.
       # Force the cached credentials to be cleared. 
       sudo_real -k "[email protected]"
   fi
   

3. Make the new /usr/bin/sudo executable:

   chmod a+x /usr/bin/sudo
   

4. Alias sudo to update the bash history when you run it from a shell by putting this in your ~/.bashrc:

   alias sudo="history -a;sudo"
   

Now, when YOU run sudo ... it will put the sudo ... into the bash history and the script will find it and run sudo_real. But when another script runs sudo, it won't be in the history, and it'll call sudo_real -k.

I think this is incredibly hairy, and I'd just live with the risk or use a new shell for scripts I didn't trust, personally :-)

How can you differentiate between a script and an executable binary command?

Of course you can think of defining a function named sudo that will have the sanity checks before running the actual binary but

• As the script can have any name, what if a script has a name like ls? So checking for extensions like .sh won't help
• Also reading shebang as the first line of the script won't help too because a script can run without having a shebang

I think, if you are too paranoid about it, you can think of disabling password caching altogether by creating an alias like:

alias sudo='sudo -k'

and put it in your ~/.bashrc.

My stance on this issue is this : if you are unsure whether or not you may or may not run an app with root privillege while your credentials still haven't timed out, then just disable the timeout at all, make it 0. Specifically you need this setting in your /etc/sudoers file:

Defaults    timestamp_timeout=0

Man page defines it like so:

 timestamp_timeout
                   Number of minutes that can elapse before sudo will ask
                   for a passwd again.  The timeout may include a frac‐
                   tional component if minute granularity is insufficient,
                   for example 2.5.  The default is 15.  Set this to 0 to
                   always prompt for a password.  If set to a value less
                   than 0 the user's time stamp will never expire.  This
                   can be used to allow users to create or delete their
                   own time stamps via “sudo -v” and “sudo -k” respec‐
                   tively.

However, if you intend to be prudent, you can define the following function in .bashrc

sudo_check()
{
  real_path="$( realpath $1 )"
  file "$real_path" | grep -q -i script
  if [ $? -eq 0 ]; then
     grep -q 'sudo' "$real_path"  && \
     { echo '>>> ALERT: Its a script that requests sudo';
       echo '    resetting sudo timestamp';
       echo 'please rerun with sudo appended ';
     }
     sudo -k
  else
     sudo "[email protected]"
  fi

}

This function will check whether or not a script contains call to sudo and alert you of that. Bellow is example of me running that function on a script ( which is my login screen background changer by the way )

$ sudo_check sergrep/chgreeterbg.sh                            
>>> ALERT: Its a script that requests sudo
    resetting sudo timestamp