Cómo permitir a los usuarios ejecutar un script sin revelar información protegida

Cómo permitir a los usuarios ejecutar un script sin revelar información protegida

Dado que el usuario root tiene algunas credenciales (por ejemplo, una clave API) configuradas en una variable de entorno, y dado un usuario sin privilegios, John, ¿cómo puedo permitir que John ejecute un script queusos¿Dicha clave API sin el riesgo de revelar su valor a John?

Respuesta1

La pregunta parece un poco desenfocada.

  • La pregunta,per se, habla de obtener un valor de una “variable de entorno de superusuario” (es decir, una “variable de entorno raíz”). Ni siquiera estoy seguro de lo que eso significa. ¿Está diciendo que John debería obtener el valor del entorno de un (otro) usuario que inició sesión como "root" o que se ejecuta como "root" a través de suo sudo? ¿O estás hablando del entorno de unproceso (probablemente un proceso en segundo plano) ejecutándose como "root"?

    Pero, sean cuales sean los detalles que tengas en mente, parece que la clave es muy dinámica y efímera. Como no entiendo lo que esto significa, no diré que sea imposible, pero suena difícil.

  • Pero luego, en un comentario, hablas de hacer que un script sea ejecutable pero no legible. Esto sugiere que está dispuesto a tener la clave codificada en el script, siempre que los usuarios que no sean root no puedan leerla. Esto sugiere que la clave es muy estática y cambia tan raramente que está dispuesto a modificar el script cada vez que cambia la clave.

    U&Ltiene un hilo largo sobre este mismo tema: ¿Puede un script ser ejecutable pero no legible?  Lamentablemente, la mayoría de las respuestas son negativas o son desviaciones, desvíos o soluciones alternativas, algunas de las cuales funcionan mejor que otras. Por ejemplo,Santana sugierecrear una entrada /etc/sudoers que le permita a Johncorrerel script con permisos elevados, sin poder leerlo como él mismo. Pero, si el script no necesita permisos elevados (aparte de obtener la clave), no querrás ejecutarlo con permisos elevados.

    Sin embargo, enesta pregunta relacionada (en superusuario), presento una manera torpe de hacer que un script sea ejecutable pero no legible envolviéndolo en un programa C. Como explico en esa respuesta, esta técnica no es infalible; Hay formas en que la información puede filtrarse.

  • La interpretación más razonable/plausible, en mi humilde opinión, es que la clave se guarda en un archivo que John no puede leer. La forma tradicional de implementar tales acuerdos es setUID y/o setGID. ( sudotambién es útil.)

A continuación se muestra un ejemplo de cómo hacerlo. Escriba un programa en C como este:

#incluir <stdio.h>
#incluir <stdlib.h>

#definir KEY_FILE        (nombre de ruta apropiado)
#definir GUIÓN          (nombre de ruta apropiado)

principal()
{
        ARCHIVO *key_fp;
        clave de carácter[80];        (ajustar según corresponda)
        gid_t gid;
        uid_t uid;
        char *argumentos[10];      (ajustar según corresponda)

        key_fp = fopen(KEY_FILE, "r");
        si (key_fp == NULL)
        {
                perror(KEY_FILE);
                salir(1);
        }
        (tu código para leer y validarllave)
        fclose(clave_fp);
        si (setenv("CLAVE", clave, 1) != 0)
        {
                fprintf(stderr, "Problema con setenv().\n");
                salir(1);
        }
        gid = getgid();
        uid=getuid();
        // usar
        // si (setresgid(gid, gid, gid) != 0 || setresuid(uid, uid, uid) != 0)
        // si están disponibles; de lo contrario
        si (setregid(gid, gid) != 0 || setreuid(uid, uid) != 0)
        {
                fprintf(stderr, "Problema al quitar privilegios.\n");
                salir(1);
        }
        args[0] = "nombre del script";     (ajustar según corresponda)
        argumentos[1] = NULO;
        execv(SCRIPT, argumentos);
        perror(guión);
        salir(1);
}

Defina KEY_FILEel nombre de ruta completo del archivo que contiene la clave y defina SCRIPTel nombre de ruta completo del archivo que contiene el script. Asegúrese de que John tenga acceso de lectura al script, pero no al archivo clave, y que no tenga acceso de escritura a ninguno de los directorios en ninguna de las rutas. Haga arreglos para que este programa pueda leer el archivo de clave configurándolo en setUID y/o setGID. Leerá la clave, la insertará en el entorno, eliminará privilegios y ejecutará el script. (Es posible que desee modificar el código anterior para que los argumentos de la línea de comandos proporcionados al programa se pasen al script).

Como se indicó anteriormente, el script se ejecutará con el UID y el GID de John, pero con la clave en el entorno. En algunos sistemas, es posible que John lea el entorno del script desde o con . Si es así, podría resultar útil que el script copie inmediatamente la clave a una variable local (no exportada) y desactive la variable./proc/(pid_of_script)/environpsKEY

Probablemente será seguro que el script pase la clave a un programa.

  • a través de una tubería (por ejemplo, ),printf "%s" (key_value) | (program)
  • a través de un documento aquí, o
  • a través de una cadena aquí.

Los riesgos de pasar el valor a través del medio ambiente se mencionan anteriormente. Evite pasarlo como parámetro de línea de comandos, ya que esto definitivamente puede verse mediante ps.

Si desea que el programa se pueda ejecutar a través de sudo, es posible que necesite codificar el UID y el GID de John, ya que sudoestablece los ID reales además de los efectivos.

información relacionada