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


3

Si j'exécute une commande sudo, elle me demandera un mot de passe, mais dans cette session Terminal pour les prochaines minutes, elle me permettra d'exécuter les commandes sudo sans me demander de mot de passe car elle mettra en cache ce que je suis autorisé.

C'est bon pour la commodité, et je trouve cela plutôt pratique, donc je ne veux pas résoudre ce problème en signifiant qu'il demande un mot de passe à chaque fois au lieu de la mise en cache.

Mais ce que j'ai trouvé récemment est quelque chose d'assez inquiétant, si je crée un petit script comme celui-ci par exemple:

#!/bin/bash

sudo rm -rf /

Et je l'exécute en tant qu'utilisateur normal dans Terminal avant d'avoir exécuté les commandes sudo, alors tout va bien et fonctionne comme prévu, il me demande le mot de passe sudo.Cependant, si je dois exécuter une commande sudo avant d'exécuter ce script sans sudo, il mettra en cache que les commandes sudo ne devraient pas demander de mot de passe pendant quelques minutes dans cette session et même si je n'ai pas donné lescript sudo privilèges il ne me demandera pas de mot de passe et le script sera autorisé à exécuter toutes les commandes sudo qu'il veut.

Maintenant, je ne suis pas du genre à exécuter de nombreux scripts sans savoir ce qu'ils contiennent, mais parfois je dois installer des éléments à partir d'un script que j'ai obtenu d'un emplacement de confiance, mais je ne sais pas avec certitude s'il n'y en a pasquelque chose de mauvais dans le script, donc je voudrais avoir la tranquillité d'esprit que cela ne va pas simplement détourner la capacité sudo qui a été accordée à ma session Terminal.

Ma question est donc la suivante: est-il possible de faire en sorte que je puisse exécuter les commandes sudo et il le mettra en cache pour moi, mais si j'exécute un script pas avec sudo pour le script nonpour pouvoir simplement détourner cette capacité?Je comprends que mon exécution du script est fondamentalement la même chose que moi qui exécute simplement les commandes du script dans l'ordre dans lequel elles se trouvent, mais n'y a-t-il pas un moyen de faire quelque chose d'intelligent pour qu'il fonctionne d'une manière légèrement différentesudo est limité aux scripts que j'exécute?

En fait, tout ce que je n'ai pas exécuté avec sudo ne devrait pas pouvoir exécuter des choses avec sudo.Y compris les commandes.S'ils ne font que détourner la capacité mise en cache qui est ...

J'utilise Ubuntu GNOME 15.10 avec GNOME 3.18.

J'ai une suggestion sur la façon dont cela pourrait être fait mais je ne connais pas les aspects pratiques de ceci: pourrais-je faire en sorte que lorsque j'exécute une commande et qu'elle commence à l'exécuter, il la consigne dans un fichier (comme c'est faitavec toutes les commandes du terminal bien que peut-être un peu trop tard pour cela - avec la commande sudo5) et ensuite, lorsque sudo est exécuté, il vérifie si j'ai exécuté cette commande dans le terminal (via l'utilisation du journal qui enregistre quand je le fais) et sinon alorsil est supposé que ce n'est pas de moi, donc il me demande un mot de passe?

5

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 :-)


2

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.


4

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