2010-09-17 12 views
21

Sto configurando un chroot minimo e voglio evitare di avere sudo o su in esso, ma continuo a eseguire i miei processi come non root. Questo è un po 'un trucco come eseguire chroot requiers root. Potrei scrivere un programma che fa questo che avrebbe un aspetto simile:Come eseguire un comando in un chroot jail non come root e senza sudo?

uid = LookupUser(args[username]) // no /etc/passwd in jail 
chroot(args[newroot]) 
cd("/") 
setuids(uid) 
execve(args[exe:]) 

è che la mia scommessa migliore o c'è uno strumento standard che lo fa per me?


ho arrotolato la mia here:

risposta

23

Se invochi chroot dall'opzione radice, l'opzione chroot ti aiuterà. Il comando chroot ha un'opzione --userspec=USER:GROUP da eseguire in UID/GID non root.

A proposito, l'opzione '--userspec' viene prima introdotta in coreutils-7.5 in base a un repository git git://git.sv.gnu.org/coreutils.

+0

Sembra esattamente quello che voglio ma non riesco a trovare la documentazione su di esso. (Sto guardando le pagine man e info.) Hai un link ad alcuni documenti? – BCS

+0

Mi dispiace ma sembra che l'opzione '--userspec' sia stata introdotta RHEL> = 6.0 o Fedora> = 13. – kamae

16

fakechroot, in combinazione con fakeroot, vi permetterà di fare questo. Faranno in modo che tutti i programmi in esecuzione agiscano come se fossero eseguiti in un chroot come root, ma in realtà verranno eseguiti come te.

Vedere anche fakechroot's man page.

+2

ho bisogno di un vero e proprio chroot come ho intenzione di essere la compilazione e l'esecuzione di codice non attendibile che potrebbe includere inline. – BCS

+1

Da quando mi sono imbattuto in questo thread, anche anni dopo, ho bisogno di aggiungere: non usare mai chroot per sicurezza. https://lwn.net/Articles/252794/ – domenukk

8

È possibile utilizzare le funzionalità di linux per fornire al proprio binario la possibilità di chiamare chroot() senza essere root. Ad esempio, puoi farlo al binario chroot. Come non root, normalmente si otterrebbe in questo modo:

$ chroot /tmp/ 
chroot: cannot change root directory to /tmp/: Operation not permitted 

Ma dopo aver eseguito il comando setcap:

sudo setcap cap_sys_chroot+ep /usr/sbin/chroot 

E ti consente di fare la chiamata chroot.

Non è consigliabile eseguire questa operazione con il sistema chroot, anziché farlo sul proprio programma e chiamare chroot. In questo modo hai più controllo su ciò che sta succedendo, e puoi persino eliminare il privilegio cap_sys_chroot dopo averlo chiamato, così le successive chiamate a chroot nel tuo programma falliranno.

+0

In questo modo si consente a un utente arbitrario di richiamare la chiamata di sistema chroot tramite qualsiasi binario a cui si accede come '/ usr/sbin/chroot'? Ciò consentirebbe quindi a qualsiasi processo all'interno di un chroot di richiamare la chiamata di sistema chroot purché possa creare un file eseguibile denominato '/ usr/sbin/chroot' relativo alla root corrente. - Preferirei non farlo allentando il modello di sicurezza dei kernel. – BCS

+0

Ho aggiornato la risposta per riflettere sul fatto che l'impostazione su chinot binary era solo un esempio. Vorresti fare quel setcap sul tuo file binario. –

8

Un chrooter personalizzato non è affatto difficile da scrivere:

#define _BSD_SOURCE 
#include <stdio.h> 
#include <unistd.h> 
const char newroot[]="/path/to/chroot"; 
int main(int c, char **v, char **e) { 
    int rc; const char *m; 
    if ((m="chdir" ,rc=chdir(newroot)) == 0 
     && (m="chroot",rc=chroot(newroot)) == 0 
     && (m="setuid",rc=setuid(getuid())) == 0) 
      m="execve", execve(v[1],v+2,e); 
    perror(m); 
    return 1; 
} 

fare quel setuid root e di proprietà di un gruppo personalizzato si aggiunge l'utente preferito a (e nessun 'altra' accesso).

1

Si potrebbe utilizzare Linux Containers per creare un ambiente chroot che si trova in uno spazio dei nomi totalmente diverso (IPC, filesystem, e anche di rete)

C'è anche LXD che è in grado di gestire la creazione di contenitori basati su immagini e configurarli per essere eseguiti come utenti non privilegiati in modo che se il codice non fidato riesce a scappare in qualche modo dal contenitore, sarà in grado di eseguire il codice solo come utente non privilegiato e non come root del sistema.

Ricerca 'Linux Containers' e 'LXD' sul vostro motore di ricerca preferito;)

Problemi correlati