Stavo pensando che potrebbe essere vantaggioso avere un utente con autorizzazioni superiori all'utente root.

Vedete, vorrei mantenere tutte le attività e quasi tutti i privilegi di utente root esistenti esattamente come sono ora.

Tuttavia, vorrei la possibilità di negare i privilegi di root su una base caso per caso estremamente isolata.

Uno dei vantaggi di questo mi consentirebbe di impedire l'installazione di determinati file indesiderati durante gli aggiornamenti. Questo è solo un esempio di un possibile vantaggio.

Poiché gli aggiornamenti di apt-get sono eseguiti da root o con i privilegi di sudo, apt-get ha la capacità di sostituire alcuni file indesiderati durante gli aggiornamenti.

Se potessi negare questi privilegi a questi singoli file particolari, potrei impostarli come un collegamento simbolico /dev/nullo possibilmente avere un file segnaposto vuoto che potrebbe avere autorizzazioni che negherebbero la sostituzione del file durante l'aggiornamento.

Inoltre, non posso fare a meno di essere ricordato di una frase che è stata detta in un'intervista con uno dei creatori di Ubuntu quando il ragazzo ha detto qualcosa su come gli utenti si fidano di "noi" (riferendosi agli sviluppatori di Ubuntu) "perché abbiamo root "che era un riferimento a come gli aggiornamenti di sistema vengono eseguiti con il permesso di root.

Semplicemente modificare la procedura di installazione per dire che aggirare questo problema non è assolutamente quello che mi interessa qui. Ora che la mia mente ha un gusto per l'idea di avere il potere di negare l'accesso alla radice, vorrei trovare un modo per farlo accadere solo per il gusto di farlo.

Ho appena pensato a questo e non ho passato molto tempo sull'idea finora e sono abbastanza fiducioso che questo possa essere capito. Tuttavia, sono curioso di sapere se questo è già stato fatto o se questa non è forse una nuova idea o concetto.

Fondamentalmente, sembra che ci dovrebbe essere un modo per avere un super superutente che avrebbe l'autorizzazione oltre quella del sistema di un solo grado.

Nota: anche se ritengo che la risposta accettata corrisponda maggiormente ai criteri, mi piace molto la risposta di @CR. anche.

Vorrei creare un utente reale più in alto sull'albero (io) ma immagino che dovrò semplicemente sedermi un giorno quando avrò il tempo di capirlo.

Inoltre, non sto provando a scegliere Ubuntu qui; Non lo userei come distro principale se mi sentissi negativo.

L '"utente" desiderato si chiama LSM: modulo di sicurezza Linux. I più noti sono SELinux e AppArmor.

In questo modo puoi impedire ad alcuni binari (e ai loro processi figlio) di fare determinate cose (anche se il loro UID è root). Tuttavia, è possibile consentire queste operazioni gettye i relativi processi figlio in modo da poterlo eseguire manualmente.

Stai fraintendendo il concetto di rootutente.

In parole povere, rootè alla "cima dell'albero".

E se un giorno decidessi di avere un "super super user", e poi il mese prossimo un "super super super user" (!). Fino a che punto "in alto" l'albero vorresti andare? Come mescoleresti tutte le autorizzazioni e la gerarchia per farlo funzionare? Chi è sempre al top? Qualcuno deve essere al top, ed è root. Fine della storia.

Le soluzioni fornite qui - inclusi AppArmor e SELinux - non cambiano davvero questo. Consentono semplicemente un controllo più accurato delle rootautorizzazioni e dei processi.

Mi sembra che il tuo processo di aggiornamento non sia adatto al risultato desiderato. Ma non è affatto colpa rootdell'utente. Invece di complicare eccessivamente le cose, pensa rootall'utente delle autorizzazioni di livello più alto, e poi tutto il resto, devi lavorare verso il basso.

So che alcune persone lo segneranno, ma non esiste un livello superiore nella gerarchia degli utenti e tutte le altre soluzioni danno semplicemente un controllo leggermente diverso al funzionamento delle rootautorizzazioni. Ma non creano un nuovo utente, con autorizzazioni più elevate.

Non è possibile avere un utente con "più autorizzazioni" rispetto a rootperché rootrappresenta il livello più alto possibile di autorizzazioni. L'uso di una frase come "più controllo di root" è una contraddizione: rootha il pieno controllo e tutte le autorizzazioni possibili, quindi non c'è nulla che possa essere fatto al di sopra di esso.

Se vuoi solo impedire che file o directory vengano modificati / cancellati, imposta semplicemente il flag immutabile su di essi.

chattr +i <file>

Nemmeno root sarà in grado di far nulla se non viene rimosso il flag. È anche possibile utilizzare il sistema container / namespace per impedire l'accesso come root ma sembra eccessivo per quello che ti serve.

• Invece di avere un super-super-utente, puoi limitare root. vedi Quali sono i diversi modi per impostare i permessi dei file ecc. su gnu / linux

• Esistono anche AppArmor e SELinux.

• E / O configura sudo, in modo da non dare via i privilegi di root completi. È possibile configurarlo in modo che un utente possa eseguire solo comandi prestabiliti, con argomenti concordati.

• Puoi anche usare la virtualizzazione per limitare il root:

  • cgroups, namespace, chroot etc (docker fa questo)
  • Xen
  • virtualbox

• Guarda anche etckeeper : questa revisione dello strumento controlla la /etcdirectory e si sincronizza con apt. Per impostazione predefinita, non è sicuro, un'installazione dannosa potrebbe sabotare, ma potresti anche far sì che invii modifiche a un repository di backup con firewall.

• Utilizzo del controllo di revisione in generale, con un repository di backup con firewall. Questo aiuta con corruzione accidentale, intenzionale e guasti hardware.

I repository di backup con firewall potrebbero trovarsi su una macchina diversa, su Internet o su una macchina virtuale (o host di macchina virtuale) diversa.

Per software come APT , che nel normale funzionamento richiedono l'accesso a quasi tutto il sistema, la limitazione è problematica. Anche se gli impedisci di accedere ad alcune parti del sistema, molto probabilmente ci sono possibilità più che sufficienti per aggirare il distributore malevolo. Ad esempio sostituendo una libreria o semplicemente un file binario o aggiungendo una modifica di configurazione dannosa, che alla fine verrà utilizzata dalla radice senza restrizioni.

A seconda di quanto porteresti restrizioni, ci si può aspettare che alcuni script di installazione si rompano.

Per modi per limitare applicazioni e utenti, è possibile scrivere un criterio AppArmor o SELinux. Tale politica sarebbe più supportata dipende dalla vostra distribuzione: basata su Debian ha un supporto migliore per AppArmor mentre le distribuzioni basate su Fedora / RHEL abilitano SELinux di default.

Sia AppArmor che SELinux lavorano su policy di white list , che contengono regole per consentire (o negare) azioni specifiche. I criteri vengono applicati a un processo presso exec , allo stesso modo gli utenti possono essere limitati quando un criterio viene applicato ai loro processi al momento dell'accesso. Una politica ben ponderata non può essere aggirata (se i bug del kernel non vengono considerati). Il processo limitato in esecuzione come root (uid 0) è limitato dalla politica configurata e non può cambiarlo se non esplicitamente consentito nella politica.

Il linguaggio dei criteri di AppArmor definisce una regola di rifiuto , che può essere utilizzata per creare un criterio della lista nera . Un buon punto di partenza con AppArmor sono le pagine man di AppArmor , wiki e la ricerca della configurazione esistente sulla tua distribuzione/etc/apparmor.d/ .

Molto materiale di amministrazione e sviluppo di SELinux è fornito nel wiki SELinux . La politica di riferimento di SELinux è ospitata su github.

Non riesco a credere che nessuno abbia menzionato l'appuntamento appropriato ...

Un paio di anni fa, Microsoft ha rilasciato una patch che ha impedito alle macchine Windows 10 di parlare con i nostri vecchi controller di dominio Samba NT4. Quando il problema è stato rilevato, abbiamo aggiunto il pacchetto Samba per rimanere alla versione corrente e aptfunzionava ancora correttamente.

Una procedura dettagliata Debian spiega bene il processo:

In /etc/apt/preferences(o un nuovo file in /etc/apt/preferences.d/), aggiungi del testo per specificare quale pacchetto e versione:

Package: samba
Pin: release v=3.6.6-6+deb7u7
Pin-Priority: 900

Controlla la documentazione per la sintassi esatta, ma questo è il modo rapido e sporco in cui abbiamo aggiunto una versione del pacchetto. Il root potrebbe bypassarlo, come sempre può fare il root, ma questo risolve il problema dei gestori dei pacchetti che provano ad aggiornare automaticamente i pacchetti su di te.

NOTA: questa risposta presuppone che tu abbia un problema XY

In realtà è abbastanza semplice.

Il root è il tuo "super super user"

Crea un account chiamato "admin" e dagli tutte le autorizzazioni di root tranne quella che non vuoi.

Quindi crea un utente chiamato bob e lascia che "diventi admin". Usando su o persino sudo.

Ora hai un utente normale (bob) un super utente che può fare cose da amministratore (admin) e un super utente super (root).

Se vuoi cambiare il nome "root" in qualcos'altro, puoi persino farlo. Tecnicamente conta solo l'id utente (0).

Se quello che vuoi è semplicemente impedire l'installazione di file specifici, limitare le autorizzazioni di root non è il modo migliore per farlo. Vale la pena notare anche che le risposte convenzionali (file immutabili o LSM) non funzioneranno per il tuo particolare caso d'uso, in quanto APT (e la maggior parte degli altri gestori di pacchetti) salveranno se non possono installare file.

La vera domanda che vuoi porre è:

Esiste un modo per impedire a APT di installare file specifici?

Questo è qualcosa di completamente diverso da quello che stai chiedendo su più livelli.

Ora, per quanto riguarda questa domanda, non sono sicuro al 100%, ma so che molti altri gestori di pacchetti hanno opzioni per impedire l'installazione di file specifici (ad esempio, il sistema Portage di Gentoo ha l'opzione INSTALL_MASK=, che in realtà accetta la shell modelli di abbinamento stile di cose da non installare). Sarei più che disposto a scommettere che tale opzione esiste per APT (o forse dpkg stesso).

Conservare una copia di backup in un luogo sicuro. Dopo qualsiasi installazione / aggiornamento, sostituire immediatamente i file specifici da quel backup. Pertanto, nessun errore per rovinare l'installazione, ma si ottiene ancora i file che si desidera conservare.

Lavora da un'unità montata

Nota che questa è principalmente una risposta concettuale, ma penso che dovrebbe funzionare ed essere in spirito con ciò che vuoi ottenere.

Lascia che il sistema X sia il tuo sistema di lavoro e il sistema Y un altro sistema che controlli

1. Montare una directory da Y come unità in X
2. Imposta i diritti in modo tale che l'utente root di X disponga dei diritti su tutto in questa unità montata, con alcune eccezioni

Ora hai la tua "radice funzionante" che può fare quasi tutto, e hai la tua "super radice", l'account radice reale del sistema Y, che può davvero fare tutto.

È possibile eseguire un hypervisor di tipo 1 come l'hypervisor Xen e avere quello che ospita il proprio sistema operativo normale come guest virtualizzato. L'hypervisor controlla il sistema operativo guest virtuale a un livello "più profondo" rispetto al root perché ha il controllo sull'hardware (virtuale) su cui è in esecuzione il sistema operativo guest.

È possibile programmare l'hypervisor per manipolare il sistema operativo guest in vari modi, tra cui la modifica delle autorizzazioni, la creazione e l'applicazione di backup, l'aggancio di alcune modifiche o istruzioni nel sistema operativo guest per iniettare funzionalità aggiuntive, convalida, ecc. Sarebbe un modo valido e potenzialmente utile implementare un sistema di tipo unix con un "utente" (in realtà una funzione dell'hypervisor) per "fare cose che anche root non può fare"

Tuttavia, ho la sensazione che questo approccio sia probabilmente eccessivo

Dai un'occhiata ai cgroups e agli spazi dei nomi Linux come metodo alternativo per raggiungere questo tipo di obiettivo, nonché strumenti basati su di essi come Docker e lxd .

Questi strumenti consentono, tra le altre cose, di limitare quali parti del file system possono vedere un processo in esecuzione come "root", limitare quali processi sono visibili ad esso e fornire solo determinate funzionalità all'utente "root".

UNINSTALL sudo

Che ne dici di disinstallare sudoe symlink /bin/sua /bin/false? Abbinalo assicurandoti che rootnon sia possibile accedere tramite sshe hai bloccato il sistema.

Ciò rende rootSuper * Super User e tutti gli altri sono subordinati a questo.

Per i file sostituiti durante gli aggiornamenti, semplicemente non eseguire alcun aggiornamento. Più realisticamente, cambiare i permessi del file 440o 444in modo che non possono essere scritti. Oppure inseriscili in un repository git, quindi se vengono sovrascritti, possono essere ripristinati.