Diritti limite per le applicazioni utente

Question

Diritti limite per le applicazioni utente

#1 da (3 voti)

2

Ho un sito web, dove gli utenti sono disponibili per caricare piccole applicazioni che funzionano 24 ore su 24, 7 giorni su 7 sul mio server.

Quindi, se l'utente carica un'applicazione, verranno create alcune cartelle:

/{USER_ID}/{APP_ID}/

(se la cartella utente esiste già, la cartella /{USER_ID}/ non verrà più creata)

All'interno di questa directory, i file dell'applicazione verranno archiviati. Per ogni applicazione creata dall'utente, verrà creato un file bash all'interno della cartella /{APP_ID}/ che contiene il comando di avvio per l'applicazione.

Ad esempio, se l'utente carica un'applicazione NET Core , verrà creato un file bash che contiene nohup dotnet app.dll ... .

La mia domanda è: come posso proteggere il mio server nel modo migliore per limitare i diritti delle applicazioni dell'utente.

Se l'utente ha creato l'applicazione, può fare clic su un pulsante di avvio sul sito Web che eseguirà il file bash start.sh .

Che cos'è, se l'applicazione caricata dall'utente modifica il contenuto del file bash che può danneggiare il server?

Voglio impedirlo rendendo il file bash non modificabile / mobile / cancellabile ecc.

Ma immagino che tu possa fare più cose cattive per danneggiare il server.

Quindi, come posso evitare che l'utente abbia solo i diritti di fare cose all'interno della propria cartella ( /{USER_ID}/ ) [solo userid perché non mi interessa se l'utente danneggia le sue applicazioni].

La mia idea è che se la directory ( /{USER_ID}/ ) verrà creata per prima, php creerà un utente sul mio server con i soli diritti all'interno della cartella /{USER_ID}/ .

Questo sarà abbastanza sicuro?

Il mio sistema operativo è Ubuntu 16.04.

php ubuntu laravel

posta xKushGene 17.10.2018 - 19:50

fonte

1 risposta

Leggi altre domande sui tag php ubuntu laravel

Specialista in sicurezza informatica vs. consulente vs. architetto [chiuso] E 'possibile dire se il digest di messaggi di un file è MD5 o SHA-256?

score 3 · Answer 1

Solo isolare l'accesso al filesystem non è abbastanza da solo per proteggere il resto del sistema, ed è anche notoriamente difficile da fare correttamente ( chroot può essere facilmente sfuggito, SELinux è un rompicoglioni da configurare, ecc. ). Tra gli altri potenziali mezzi di attacco hai:

Oggetti IPC (semafori, code di messaggi POSIX, segnali, ecc.). Non esiste un modo semplice per limitare quale processo può manipolare quali oggetti IPC, ma bloccarli globalmente causerà la violazione di molti programmi legittimi.
Accesso alla rete. È facile da bloccare, ma ovviamente non è coperto limitando l'accesso al filesystem.
Alcuni tipi di limitazioni delle risorse sono in realtà piuttosto semplici da eseguire come utente normale (affinità della CPU, ad esempio).
Senza alcuno sforzo da parte tua, i tuoi nuovi utenti avranno un accesso abbastanza semplice a determinati tipi di hardware sul sistema.
Anche a parte quanto sopra, c'è un lotto di chiamate di sistema che non dovrebbero mai essere chiamate da un normale codice utente ma possono essere ( vm86 e iopl sono probabilmente due dei migliori esempi ).

Idealmente, supponendo che tu non voglia gestire complicate impostazioni manuali, cerca uno strumento come firejail . Anche se non è progettato per questo esatto caso d'uso, dovrebbe essere piuttosto semplice adattarsi ad esso, ed è praticamente semplice da configurare rispetto alla maggior parte del software sandbox. Con una configurazione sana, firejail può:

Limita in modo sicuro l'accesso al filesystem in un modo facile da configurare.
Allo stesso modo protegge gli oggetti IPC.
Limita l'utilizzo delle funzionalità.
Limita l'accesso alla rete, possibilmente utilizzando una configurazione di rete completamente diversa dal sistema host.
Forza l'affinità CPU specifica.
Spoof una varietà di informazioni di identificazione comuni per il sistema (nome host, ID macchina, dati riportati da uname , ecc.)
Non consentire l'esecuzione di memoria che è o era scrivibile (solo su alcune architetture).
Disabilita l'accesso a un'ampia varietà di hardware che potrebbe altrimenti essere accessibile.
Impedisce esplicitamente l'esecuzione del codice in determinate directory.
Rendi certe directory effimere (perderanno lo stato quando la sandbox si chiude, ottimo per garantire che i file temporanei vengano ripuliti).
Imposta e applica vari limiti di utilizzo delle risorse per i processi all'interno della sandbox.
Blocca esplicitamente le chiamate di sistema specifiche (il profilo predefinito con questo abilitato bloccherà la maggior parte di quelle che non sono necessarie per la maggior parte delle applicazioni e sono un potenziale rischio per la sicurezza).