Linux Script SUID Wrapper

0

L'uso di un wrapper per eseguire uno script è una buona pratica?

In tal caso, la seguente serie di wrapper / script può essere considerata sicura:

wrapper.c

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <sys/types.h>

int main(void)
{
    if (setuid(geteuid()) != 0)
    {
        fputs(strerror(errno), stderr);
        return EXIT_FAILURE;
    }
    system("cat script | /bin/bash");
    return EXIT_SUCCESS;
}

lo script

IFS=""
/bin/echo -n "[Whoami]: "
/usr/bin/whoami

/bin/echo -n "[ls /root]: "
/bin/ls /root

Il file script non contiene alcuno shebang. Cambierà qualcosa se ne avessi aggiunto uno?

Nel Wrapper, avrei potuto semplicemente chiamare lo script perché eseguivo qualsiasi script Linux invece di inserire il suo contenuto in una shell?

    
posta Ra'Jiska 08.10.2017 - 18:14
fonte

2 risposte

1

Dato che fornisce un gateway per l'accesso privilegiato, l'uso dei programmi setuid dovrebbe essere considerato l'ultima risorsa per fornire funzionalità. Questo è solitamente sfruttato invocando un ulteriore programma da setuid - qualcosa che il tuo codice per design . Dato che non ci sono permessi insoliti su script (non ha nemmeno bisogno di essere eseguibile) c'è una mancanza di trasparenza in ciò che fa il codice. Non usare un percorso esplicito è un errore da principiante: il tuo codice può essere compromesso semplicemente cambiando $ PATH

Dato che esiste un modo ben definito di fornire tale accesso privilegiato su sistemi unix, che è stato ben testato, è ampiamente compreso e fornisce un controllo di accesso flessibile e granulare (sto parlando di sudo nel caso in cui non avessi indovinato) perché qualcuno dovrebbe voler implementare il codice sopra?

    
risposta data 08.10.2017 - 19:56
fonte
1

No questo non è considerato sicuro, non si tenta di sanificare l'ambiente in cui si sta eseguendo. Ciò consentirà all'utente malintenzionato di manipolare ciò che viene eseguito come root manipolando l'ambiente attraverso varie variabili di ambiente, da PATH a LD_PRELOAD. Le vulnerabilità specifiche variano, e c'è un certo sforzo per mitigare il caricatore dinamico, ma è comunque necessario disinfettare l'ambiente e assicurarsi di avere il controllo di ciò che viene eseguito in un contesto di privilegio assicurandosi che venga passato solo l'input rilevante e che nessun altro garantisca l'input pertinente.

    
risposta data 08.10.2017 - 18:43
fonte

Leggi altre domande sui tag