Appartenenze a gruppi e processi setuid / setgid

Processi che riducono i privilegi tramite setuid()e setgid()non sembrano ereditare le appartenenze ai gruppi dell'uid / gid che hanno impostato.

Ho un processo server che deve essere eseguito come root per aprire una porta privilegiata; successivamente si riduce a uno specifico uid / gid non privato, ¹ - ad esempio, quello dell'utente foo(UID 73). L'utente fooè un membro del gruppo bar:

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

Quindi, se accedo come foo, posso leggere un file /test.txtcon queste caratteristiche:

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

Tuttavia, il seguente programma C (compilare std=gnu99), quando si esegue 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;
}   

Segnala sempre Autorizzazione negata . Immagino che ciò abbia a che fare con il fatto che si tratta di un processo senza accesso, ma in un certo senso ha i muscoli posteriori della coscia nel modo in cui dovrebbero funzionare le autorizzazioni.

^{1. Che è spesso SOP per i server, e penso che ci debba essere un modo per aggirare questo dato che ho trovato un rapporto di qualcuno che lo fa con apache - apache è stato aggiunto al gruppo audio e apparentemente può quindi utilizzare il sistema audio. Certo, questo probabilmente accade in un fork e non nel processo originale, ma in realtà il caso è lo stesso nel mio contesto (è un processo figlio biforcuto dopo la chiamata setuid).}

Il problema è che setuide setgid non sono sufficienti a dare il vostro processo di tutte le credenziali di cui ha bisogno. Le autorizzazioni di un processo dipendono

• il suo UID
• il suo GID
• i suoi gruppi supplementari
• le sue capacità.

Vedere man 7 credentialsper avere una panoramica più dettagliata. Quindi, nel tuo caso, il problema è che hai impostato correttamente l'UID e GID, ma non hai impostato i gruppi supplementari del processo. E il gruppo barha GID 54, n. 73, quindi non viene riconosciuto come gruppo in cui si trova il processo.

Dovresti fare

#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, strisciando un po 'intorno alla rete. All'inizio ho pensato che APUE avrebbe tenuto tutte le risposte, ma mi sbagliavo. E la mia copia (vecchia edizione) è al lavoro, quindi ... Il capitolo 5 del Manuale di amministrazione di Unix e Linux sembra promettente, ma non ce l'ho (solo una copia delle prime due edizioni, anche al lavoro).

Le poche risorse che ho trovato (google per "demone che scrive unix") parlano tutte di passaggi importanti, come il modo di dissociarsi dal tty, ecc. Ma nulla di UID / GID. Stranamente, nemmeno l'ampia raccolta di HOWTO su http://tldp.org sembra avere dettagli. Solo excetion è di Jason Short scrittura di lasciare che un demone Linux - parte I . I dettagli completi su come funziona SUID / SGID e tutto quel casino sono demistificati il ​​SUID di Chen, Wagner e Dean (un articolo di USENIX 2002). Ma fai attenzione, Linux ha un UID in più, il FSUID (vedi le Note di incompatibilità Unix di Wolter : UID Setting Functions per una discussione).

Demonizzare un processo non è sicuramente per i deboli di cuore. Considerazioni generali sulla sicurezza sono riportate nella Programmazione sicura di D. Wheeler per Linux e Unix HOWTO - Creazione di software sicuro . Systemd promette di semplificare gran parte di ciò (e quindi di ridurre lo spazio per errori che portano a problemi di sicurezza), consultare il manuale del demone .