it-swarm-es.tech

¿Cómo evitar scripts / comandos secuestrando la capacidad de Sudo en caché de su sesión?

Si ejecuto un comando Sudo me pedirá una contraseña, sin embargo, en esa sesión de Terminal durante los próximos minutos, me permitirá ejecutar comandos Sudo sin pedirme una contraseña, ya que se guardará en caché Que estoy permitido.

Esto es bueno por conveniencia, y lo encuentro bastante conveniente, así que no quiero arreglar esto, lo que significa que siempre pide una contraseña en lugar de almacenar en caché.

Pero lo que he encontrado recientemente ha sido algo bastante preocupante, si creo un pequeño script como este, por ejemplo:

#!/bin/bash

Sudo rm -rf /

Y lo ejecuto como el usuario normal en la Terminal antes de ejecutar cualquier comando Sudo entonces todo está bien y funciona como se esperaba, me pide la contraseña Sudo. Sin embargo, si debo ejecutar un comando Sudo antes de ejecutar esta secuencia de comandos sinSudo almacenará en caché que los comandos Sudo no deberían solicitar una contraseña durante unos minutos en esta sesión y luego, aunque no le otorgué privilegios a la secuencia de comandos Sudo, no me solicitará una contraseña y la secuencia de comandos podrá ejecutar cualquier comando Sudo que desee.

Ahora no soy del tipo que ejecuta muchos scripts sin saber qué hay en ellos, pero a veces tengo que instalar cosas de un script que obtuve de una ubicación confiable, pero no estoy seguro de si no hay nada malo en el guión, por lo que me gustaría tener la tranquilidad de que no solo secuestrará la habilidad Sudo que se ha otorgado a mi sesión de Terminal.

Entonces mi pregunta es, ¿es posible hacerlo para que pueda ejecutar los comandos Sudo y me lo guardará en caché, pero luego si ejecuto un script no con Sudo para que el script no pueda simplemente secuestrar esa habilidad? Entiendo que ejecutar el script es básicamente lo mismo que ejecutar los comandos en el script en el orden en que están allí, pero no hay una manera de hacer algo inteligente para que se ejecute de una manera ligeramente diferente o para que Sudo está restringido para los scripts que ejecuto?

Sin embargo, cualquier cosa que no haya ejecutado con Sudo no debería poder ejecutar cosas con Sudo. Incluyendo comandos. Si solo están secuestrando la capacidad en caché que es ...

Estoy ejecutando Ubuntu GNOME 15.10 con GNOME 3.18.

Tengo una sugerencia de cómo se podría hacer esto, pero no sé los aspectos prácticos de esto: ¿podría hacerlo de modo que cuando ejecuto un comando y comience a ejecutarlo lo registre en un archivo (como se hace con todos los terminales comandos, aunque tal vez un poco tarde para esto, con el comando history) y luego cuando se ejecuta Sudo comprueba si ejecuté ese comando en la Terminal (mediante el uso del registro que registra cuando lo hago ) y si no es así, ¿se supone que no soy yo, por lo que me solicita una contraseña?

3
user364819

Tu puedes correr

Sudo -k

antes de ejecutar su script. Borrará las credenciales almacenadas en caché y el próximo Sudo le pedirá nuevamente su contraseña.

Aquí hay una manera de hacer lo que quieras (creo).

  1. Mueve tu Sudo a otra parte:

    mv /usr/bin/Sudo /usr/bin/Sudo_real
    
  2. Ponga lo siguiente en 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. Haga el nuevo /usr/bin/Sudo ejecutable:

    chmod a+x /usr/bin/Sudo
    
  4. Alias ​​Sudo para actualizar el historial de bash cuando lo ejecutas desde un Shell poniéndolo en tu ~/.bashrc:

    alias Sudo="history -a;Sudo"
    

Ahora, cuando USTED ejecuta Sudo ... colocará el Sudo ... en el historial de bash y el script lo encontrará y ejecutará Sudo_real. Pero cuando otro script ejecuta Sudo, no estará en el historial y llamará Sudo_real -k.

Creo que esto es increíblemente difícil, y simplemente viviría con el riesgo o usaría un nuevo Shell para scripts en los que no confiaba, personalmente :-)

5
Mark Smith

Mi postura sobre este tema es la siguiente: si no está seguro de si puede o no ejecutar una aplicación con privilegios de root mientras sus credenciales aún no han expirado, simplemente desactive el tiempo de espera, hágalo 0. Específicamente usted necesita esta configuración en su archivo /etc/sudoers:

Defaults    timestamp_timeout=0

La página del manual lo define así:

 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.

Sin embargo, si pretende ser prudente, puede definir la siguiente función en .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

}

Esta función verificará si un script contiene o no una llamada a Sudo y lo alertará de eso. A continuación se muestra un ejemplo de mí ejecutando esa función en un script (que es mi cambiador de fondo de la pantalla de inicio de sesión por cierto)

$ Sudo_check sergrep/chgreeterbg.sh                            
>>> ALERT: Its a script that requests Sudo
    resetting Sudo timestamp
4

¿Cómo puede diferenciar entre un script y un comando binario ejecutable?

Por supuesto, puede pensar en definir una función llamada Sudo que tendrá las comprobaciones de cordura antes de ejecutar el binario real pero

  • Como el script puede tener cualquier nombre, ¿qué pasa si un script tiene un nombre como ls? Por lo tanto, buscar extensiones como .sh no ayudará
  • También leer Shebang como la primera línea del script no ayudará porque un script puede ejecutarse sin tener un Shebang

Creo que si eres demasiado paranoico al respecto, puedes pensar en deshabilitar el almacenamiento en caché de contraseñas creando un alias como:

alias Sudo='Sudo -k'

y póngalo en su ~/.bashrc.

2
heemayl