Mito o realtà: SELinux può limitare l'utente root?

Ho letto o sentito da qualche parte (forse nel corso SELinux di LinuxCBT ; ma non sono sicuro) che ci sono server Linux online, per i quali viene fornita anche la password dell'utente root. Il server Linux è rinforzato usando le regole SELinux, in modo tale che tutti possano accedere con l'utente root, ma non possano danneggiare il sistema operativo.

Mi sembra un mito, ma volevo assicurarmi: è possibile rendere più duro un box Linux (possibilmente con SELinux), in modo che anche l'utente root non possa fare specifiche attività dannose su di esso? (Esempi: eliminazione di file di sistema, cancellazione di file di registro, interruzione di servizi critici, ecc.)

Una tale scatola Linux sarà un ottimo punto di partenza per costruire un honeypot .

Modifica: sulla base di una risposta (ora eliminata) e di un po 'di Google, ho ottenuto almeno due collegamenti che indicavano tali server Linux rinforzati. Sfortunatamente, entrambi i server sono inattivi. Per la cronaca, copierò e incollerò le descrizioni qui:

1) Da http://www.coker.com.au/selinux/play.html :

Accesso root gratuito su una macchina Linux SE!

Per accedere alla mia macchina da gioco Debian ssh su play.coker.com.au come root, la password è ...

Si noti che tali macchine richiedono molta abilità se si desidera eseguirle correttamente. Se devi chiedere se dovresti eseguirne uno, la risposta è "no".

Lo scopo è quello di dimostrare che SE Linux può fornire tutta la sicurezza necessaria senza alcuna autorizzazione Unix (tuttavia si consiglia comunque di utilizzare le autorizzazioni Unix anche per server reali). Inoltre ti dà la possibilità di accedere a una macchina SE e vedere com'è.

Quando si accede a una macchina da gioco SE Linux assicurarsi di utilizzare l' opzione -x per disabilitare l'inoltro X11 o impostare ForwardX11 no nel file / etc / ssh / ssh_config prima di accedere. Assicurati anche di usare l'opzione -a per disabilitare l'inoltro dell'agente ssh o impostare ForwardAgent no nel tuo file / etc / ssh / ssh_config prima di accedere. Se non disabiliti correttamente queste impostazioni, l'accesso alla macchina da gioco rischi di essere attaccato dal tuo client SSH.

C'è un canale IRC per discuterne, è #selinux su irc.freenode.net .

Ecco una breve FAQ

2) Da http://www.osnews.com/comments/3731

Gentoo Hardened 's scopo è di rendere Gentoo praticabile per alta sicurezza, ambienti ad alta stabilità dei server di produzione. Questo progetto non è un progetto indipendente disgiunto da Gentoo; è destinato a essere un team di sviluppatori Gentoo che si concentrano sulla fornitura di soluzioni a Gentoo che forniscano sicurezza e stabilità elevate. Questa macchina è la macchina demo SELinux di Gentoo temprata . Il suo uso principale è testare e controllare l'integrazione e la politica di SELinux.

Realtà: sì, SELinux può limitare l'utente root.

Questo è possibile perché SELinux non si preoccupa effettivamente dell'attuale utente Unix: tutto ciò che vede è un metadata supplementare chiamato contesto (che include, tra gli altri campi, un campo di dominio ) e che consente a SELinux di decidere se l'azione richiesta può essere autorizzata o non.

Quello che uno di solito concepisce come utente root verrebbe mappato in SELinux come utente Unix root che esegue i domini unconfined_to sysadm_tSELinux. È l'utente root onnipotente classico a piena potenza.

Tuttavia, si potrebbe configurare perfettamente il proprio sistema per generare una shell root (intendo la shell utente Unix root) che esegue il user_tdominio SELinux dell'utente con restrizioni . Secondo le politiche di SELinux, tale shell non sarebbe diversa da qualsiasi altra shell di utenti con restrizioni e non avrebbe alcun privilegio speciale sul sistema, confinando così in modo efficace l'utente root.

Appartire da un punto di vista sperimentale, fare una cosa del genere letteralmente è inutile, tuttavia pratiche simili trovano la loro strada nel mondo reale. Un classico esempio potrebbe essere un amministratore di database che deve essere in grado di arrestare / avviare i daemon del database, modificare i file di configurazione, ecc. Senza SELinux, tutte queste azioni richiederebbero all'utente di passare ai privilegi di root (anche se normalmente è per un singolo riga di comando tramite lo sudostrumento, ad esempio, anche se potrebbe essere soggetto a perdite).

Grazie a SELinux, potremmo offrire a questo utente una shell root originale, ma invece di eseguire unconfined_to sysadm_tdomini eseguirà il dbadm_tdominio. Ciò significa che avrà più privilegi di un utente con restrizioni, ma questi nuovi privilegi saranno limitati a ciò che è necessario per amministrare il server di database: questo utente non sarà in grado di manomettere altri servizi, file o eseguire altri comandi amministrativi rispetto a quelli strettamente obbligato a fare il suo lavoro.

Allo stesso modo, il server web e gli altri amministratori di servizi potrebbero anche avere altre shell root in esecuzione in parallelo sullo stesso sistema, ognuno vedrà il proprio utente Unix corrente come root , ma grazie a SELinux ognuno avrà effettivamente diversi privilegi limitati a ciò è necessario per i propri scopi .

Si è possibile. Ma non molto utile.

Si potrebbe teoricamente impedire all'utente root di eseguire file binari che potrebbero essere utilizzati per scopi dannosi, applicando politiche tramite qualcosa come SELinux. Tuttavia, ciò presenta un problema, che è che anche se all'utente root era inizialmente vietato fare qualcosa, lui o lei poteva semplicemente usare altri metodi per cambiare o rimuovere le politiche di SELinux. A causa di questo problema, dovresti effettivamente impedire all'utente root di eseguire qualsiasi azione, rendendolo non molto utile.

È possibile rafforzare un box Linux (possibilmente con SELinux), in modo tale che anche l'utente root non possa fare attività dannose specifiche su di esso?

Può sembrare economico, ma è facile: cambia l'UID dell'utente root in un valore diverso da zero. Basta andare in / etc / passwd e / etc / shadow, modificare le voci uid = 0 esistenti da "root" a qualcos'altro, quindi aggiungere un account chiamato "root" il cui uid non sia zero e non utilizzato.

Raggiunge lo scopo senza. È anche un modo per affermare che chiunque può avere "accesso root" senza effettivamente fornire privilegi di escalation.