subuser, benefit o liability? [chiuso]

Question

subuser, benefit o liability? [chiuso]

#1 da (2 voti)

1

Sto provando varie soluzioni di sandboxing su linux. Sono abituato a eseguire programmi non affidabili (ad esempio, un browser Web, un lettore di documenti PDF, ecc.) All'interno di una sandbox selinux, di cui sono abbastanza soddisfatto, ma c'è un problema: è supportato solo su rhel / fedora. Le altre distribuzioni di AFAIK in realtà non supportano selinux (anche quando dicono di farlo, non inviano politiche o documentazione utilizzabili) e anche quando viene fornita una politica quasi operativa, policycoreutils-sandbox non è disponibile (vedere debian).

Quale potrebbe essere una soluzione di sandboxing multi-distro? Sto cercando docker / subuser, che mi permette di avviare un container docker che esegue l'applicazione di interesse e dandogli accesso solo a parte del filesystem. Ad esempio, posso eseguire "chrome" in un contenitore finestra mobile e consentire solo l'accesso alla mia directory Download.

Sembra una soluzione conveniente poiché è indipendente dalla distribuzione e non richiede l'installazione del programma che sto pianificando di eseguire e delle sue dipendenze sull'host.

Tuttavia, non sono abbastanza sicuro di quanta sicurezza ci sia in "sicurezza dei subuser": link

Prima di tutto, la finestra mobile non supporta ancora gli spazi dei nomi utente. Ciò significa che ogni 'contenitore' viene eseguito come root sul mio host, anche se è isolato da lxc. questo significa anche che, se seguo i consigli del subuser, devo aggiungere il mio utente al gruppo docker. poiché dockerd viene eseguito come root, avere accesso ad esso significa che ho accesso completo all'intero filesystem host come root, posso eseguire contenitori con privilegi, ecc. Se questo non abilita l'escalation dei privilegi (anche se non dalle app "guest", Spero), non so cosa sia.

inoltre, diciamo che sto usando chrome in subuser. Ora ho un browser Chrome in esecuzione con la sandbox disabilitata (un livello in meno) all'interno di un'altra sandbox sotto l'utente root. È davvero un vantaggio semplicemente eseguire Chrome con la sua sandbox con un utente non privilegiato?

Non sarei in grado di limitare il suo accesso alla mia home directory, ma a parte questo, non vedo motivi per preferire subuser / docker.

quali altre distro soluzioni indipendenti sono rimaste?

Sto iniziando a pensare che la soluzione meno ingombrante sarebbe semplicemente utilizzare gli utenti standard di Unix. Un utente per applicazione, magari installa un'app e le relative dipendenze in ~ local, ~ bin, ecc.

quali gestori di pacchetti supportano l'installazione di un pacchetto, mantenendo un albero dei pacchetti, come utente all'interno della home directory di un utente? ci sono gestori di pacchetti di terze parti per Linux che supportano questo?

come condividerei file tra utenti? Sto pensando alla possibilità di eseguire un demone ftp non privilegiato su localhost, diciamo come utente "standard" o "storage" e utilizzare utenti virtuali per esportare parti di tale directory home (ad es. / Home / me / apps / webdownloads ) ad altri utenti, applicazioni e montarlo tramite fusibile.

È ragionevole?

sandbox

posta boh15 01.08.2014 - 08:32

fonte

1 risposta

Leggi altre domande sui tag sandbox

Modo sicuro di aprire la pagina web da iOS senza bisogno di accedere MITM è impossibile quando la voce arp del gateway è impostata su statica?

score 2 · Answer 1

Sono Timothy Hobbs, l'autore di subuser. Mi piacerebbe che prima leggi il mio articolo sulla filosofia di sicurezza del subuser in modo che tu possa vedere a cosa sto mirando. Il mio obiettivo è proteggere una vasta base di utenti dagli attacchi del mulino e non per proteggere gli utenti specificamente designati dalla NSA / altre organizzazioni criminali.

First of all, docker doesn't yet support user namespaces. This means that every 'container' runs as root on my host, even if it's isolated by lxc.

Mentre le versioni correnti di subuser creano ancora l'immagine come root, i subuser non vengono eseguiti come root se non specificatamente specificato.

this also means that, if I follow subuser's recommendations, I have to add my user to the docker group. since dockerd runs as root, having access to it means that I have full access to the whole host filesystem as root, I can run privileged containers, etc. If this isn't enabling privilege escalation (even if not from 'guest' apps, I hope), I don't know what it is.

È vero che Docker e, di conseguenza, subuser, fornisce all'utente normale i privilegi di root completi. Lo considero un difetto in Docker. Cercherò sicuramente di alleviare questo problema, se la gente Docker non lo fa per me. Tuttavia, su un singolo sistema utente, non credo che sia un problema di sicurezza per l'utente normale avere accesso root. Perché se qualcuno ottiene il controllo del normale utente, è pessimo come root . È davvero una questione su cosa stai cercando di proteggere: integrità del sistema o dei tuoi dati e della tua privacy.

furthermore, let's say that I'm running chrome in subuser. Now I have a chrome browser running with its sandbox disabled (one less layer) inside another sandbox under the root user. Is it really a benefit from simply running chrome with its sandbox under an unprivileged user?

Chrome è un caso speciale. È l'unico programma che ho incontrato che ha questa limitazione. Non è consigliabile eseguire chrome in subuser.

I'm starting to think that the least cumbersome solution would be to simply use standard unix users. One user per application, maybe install an app and its dependencies under ~local, ~bin, etc.

Ho certamente considerato questo approccio durante la progettazione di subuser. Tuttavia, la condivisione di file tra utenti è disordinata, insicura o entrambe. Inoltre, non è possibile visualizzare semplicemente x11 windows da altri utenti sul server x11 dell'utente. Devi configurare XPRA, VNC, RPC o qualche altra soluzione di rete. Questo è noioso, e uno degli obiettivi principali di subuser è quello di eliminare il tedio di una tale configurazione.

which package managers support installing a package, mantaining a package tree, as a user inside a user's home directory? are there any third party package managers for linux that support this?

Ci sono molti gestori di pacchetti che supportano l'installazione di programmi come utenti normali. È possibile visualizzare un elenco incompleto http //subuser.org/related-projects.html (reputazione insufficiente per pubblicare più di 2 collegamenti) sul sito Web del sottocontenitore. Basta scorrere verso il basso fino ad arrivare a zero-installazione. Ovviamente, questi gestori di pacchetti non fanno nulla in termini di sicurezza.

'' '' come condividerei file tra utenti? Sto pensando alla possibilità di eseguire un demone ftp non privilegiato su localhost, diciamo come utente "standard" o "storage" e utilizzare utenti virtuali per esportare parti di tale directory home (ad es. / Home / me / apps / webdownloads ) ad altri utenti, applicazioni e montarlo tramite il fusibile.

È ragionevole? '' ''

Il toolkit di sub-identità http //ccl.cse.nd.edu/software/subid/ (non abbastanza reputazione per pubblicare più di due link) fornisce uno strumento chiamato subuserchown che assiste nella condivisione di file tra utenti.