Membresías grupales y procesos setuid / setgid

Procesos que reducen los privilegios a través de setuid()y setgid()no parecen heredar las pertenencias a grupos del uid / gid que establecen.

Tengo un proceso de servidor que debe ejecutarse como root para abrir un puerto privilegiado; después de eso se reduce a un uid / gid no privilegiado específico, ¹ , por ejemplo, el del usuario foo(UID 73). El usuario fooes miembro del grupo bar:

> cat /etc/group | grep bar
bar:x:54:foo

Por lo tanto, si inicio sesión como foo, puedo leer un archivo /test.txtcon estas características:

> ls -l /test.txt
-rw-r----- 1 root bar 10 Mar  8 16:22 /test.txt

Sin embargo, el siguiente programa C (compilar std=gnu99), cuando se ejecuta root:

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>

int main (void) {
    setgid(73);
    setuid(73);
    int fd = open("/test.txt", O_RDONLY);
    fprintf(stderr,"%d\n", fd);
    return 0;
}   

Siempre informa Permiso denegado . Me imagino que esto tiene que ver con que es un proceso que no es de inicio de sesión, pero de alguna manera afecta a la forma en que se supone que funcionan los permisos.

^{1. Lo que a menudo es SOP para servidores, y creo que debe haber una forma de evitarlo, ya que encontré un informe de alguien haciéndolo con apache. Apache se ha agregado al grupo de audio y aparentemente puede usar el sistema de sonido. Por supuesto, esto probablemente ocurre en una bifurcación y no en el proceso original, pero de hecho, el caso es el mismo en mi contexto (es un proceso secundario bifurcado después de la llamada setuid).}

El problema es eso setuidy setgid no son suficientes para darle a su proceso todas las credenciales que necesita. Las autorizaciones de un proceso dependen de

• su UID
• su GID
• sus grupos suplementarios
• sus capacidades

Consulte man 7 credentialspara obtener una descripción más detallada. Entonces, en su caso, el problema es que configuró correctamente el UID y el GID, pero no configuró los grupos suplementarios del proceso. Y el grupo bartiene GID 54, no 73, por lo que no se reconoce como grupo en el que se encuentra su proceso.

Deberías hacer

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <grp.h>

int main (void) {
    gid_t supplementary_groups[] = {54};

    setgroups(1, supplementary_groups);
    setgid(73);
    setuid(73);
    int fd = open("/test.txt", O_RDONLY);
    fprintf(stderr,"%d\n", fd);
    return 0;
}  

OK, recorrí un poco la red. Al principio pensé que APUE tendría todas las respuestas, pero me equivoqué. Y mi copia (edición anterior) está funcionando, así que ... El capítulo 5 del Manual de Administración de Unix y Linux parece prometedor, pero no lo tengo (solo una copia de las dos primeras ediciones, también en funcionamiento).

Los pocos recursos que he encontrado (google para "daemon writing unix") hablan sobre pasos importantes, como la forma de disociarse del tty, etc. Pero nada sobre UID / GID. Curiosamente, ni siquiera la extensa colección HOWTO en http://tldp.org parece tener detalles. Sólo excetion es de Jason Short Vamos a un demonio de Linux - parte I . Los detalles completos de cómo SUID / SGID y todo ese desorden funcionan es el SUID de Chen, Wagner y Dean desmitificado (un documento en USENIX 2002). Pero tenga cuidado, Linux tiene un UID adicional, el FSUID (consulte las Notas de incompatibilidad de Unix de Wolter : Funciones de configuración de UID para una discusión).

Demoniar un proceso definitivamente no es para los débiles de corazón. Consideraciones generales de seguridad se dan en la programación segura de D. Wheeler para Linux y Unix HOWTO - Creación de software seguro . Systemd promete simplificar la mayor parte de eso (y así reducir el margen de errores que conducen a problemas de seguridad), consulte el manual del demonio .