Quali diritti di accesso non possono violare il superutente?

Fr. Br. George ha dichiarato in una delle sue lezioni (è in russo) che ci sono alcuni diritti di accesso che il superutente non può violare. Cioè ci sono alcuni diritti di accesso che possono vietare al superutente di fare qualcosa.

Non sono riuscito a trovare queste informazioni su Internet e sono curioso di sapere cosa siano. Questo è probabilmente qualcosa legato all'esecuzione principale del sistema, non è vero? Forse non può fermare alcuni processi di sistema? O forse non può eseguire un processo in modalità reale?

Questa domanda non è collegata a SELinux (George ne stava parlando proprio prima della domanda).

accesso negato alla radice :

rootpuò essere negato l'accesso diretto alla rete. Ciò è utile su host connessi a Internet, in quanto richiede il login come smith, quindi sudo.

alcune cose che root non può fare :

Questo NON è per mancanza di privilegi. Non riesco a vedere nulla che root non possa fare, tuttavia alcuni problemi tecnici potrebbero essere considerati "vietati".

Sono root, perché non riesco a creare / eliminare questo file, mentre l'utente ordinario può farlo?

Sei su una condivisione NFS / samba e non hai dato l' access=autorizzazione specifica ( ). L'utente ordinario non riesce alla legge comune. (vedi root locale vs remoto qui sotto)

Sono root, perché non posso uccidere questo processo?

C'è un I / O in sospeso e l'unità fisica / LUN remoto sono stati disconnessi, il processo può essere interrotto solo al riavvio.

Sono root, come posso ottenere la password di archemar?

Puoi su - archemarandare bene o cambiare la password di archemar senza conoscere la precedente, ma non puoi leggerla (a parte un registratore di chiavi), poiché le password sono memorizzate usando un hash unidirezionale.

root locale vs remoto

• Puoi essere root sulla tua stazione / PC e utilizzare una condivisione NFS di società / college / università / provider.
• Successivamente puoi avere solo un accesso non root sul computer che esporta NFS.

Adesso

cp /bin/bash /nfs/home/me/bash
chown root /nfs/home/me/bash
chmod u+s /nfs/home/me/bash

accedi semplicemente al server NFS, esegui ./bashe sei root sul server aziendale / universitario.

Nel solito caso, ciò non è corretto: il superutente ha privilegi / autorizzazioni per qualsiasi funzionalità fornita dal sistema (1). Il punto in cui questa regola viene meno quando si lancia SELinux nel mix. Con SELinux, è possibile limitare anche i privilegi di root per impedire determinate azioni. Tuttavia, le azioni specifiche vietate dipendono fortemente dalla configurazione SELinux della macchina locale, quindi anche con SELinux non è possibile rispondere a questa domanda in senso generale.

(1) - se un sistema non fornisce una determinata funzionalità, ad esempio non esiste una funzionalità del kernel in tempo reale, allora sto considerando che l'affermazione "root non ha accesso a questa funzionalità" è falsa, poiché tale affermazione si basa su un falso presupposto (vale a dire che la funzione fornita è disponibile a chiunque su quel sistema)

Da un lato, ci sono cose che nessun utente può fare, come ad esempio

• directory hard linking (a causa delle limitazioni del file system)
• scrivere su un CD-ROM già masterizzato (perché fisica)

Ma quelli non sono privilegi, perché non possono essere concessi, semplicemente non sono possibili per nessuno.

Quindi ci sono restrizioni per l'intero sistema o parti di esso che possono essere attivate o disattivate.
Ad esempio, su OS X esiste un'opzione per consentire l'esecuzione del codice solo se è stato firmato da Apple.

Non lo considero nemmeno un vero privilegio, perché nessun utente può averlo se il superutente non può. Puoi disabilitarlo solo a livello globale.

Modifica: la
tua idea di un file senza il bit eseguibile rientra anche in questa categoria, poiché letteralmente nessuno è in grado di farlo e nessuno può ottenere tale autorizzazione.
E anche quando si concede a un altro utente o gruppo l'autorizzazione per eseguire quel file, ma non è presente root o un gruppo di utenti root, root sarà comunque in grado di eseguire quel file (testato su OS X 10.10, 10.11 e Ubuntu 15.04 server).

A parte questi casi, non c'è praticamente nulla che root non possa fare.
Vi è, tuttavia, una cosa chiamata modalità kernel (al contrario della modalità utente).

Per quanto ne so, su un sistema sano solo il kernel, le estensioni del kernel e i driver funzionano in modalità kernel, e tutto il resto (compresa la shell da cui si accede come root) viene eseguito in modalità utente.
Si potrebbe quindi sostenere che "essere root non è abbastanza". Tuttavia, sulla maggior parte dei sistemi l'utente root è in grado di caricare i moduli del kernel, che a loro volta verranno eseguiti in modalità kernel, offrendo in modo efficace a root un modo per eseguire il codice in modalità kernel.

Ci sono sistemi, tuttavia, (come iOS) in cui ciò non è (arbitrariamente) possibile, almeno non senza sfruttare i sistemi di sicurezza. Ciò è dovuto principalmente alla maggiore sicurezza, come l'applicazione della firma del codice.
Ad esempio, ci sono chiavi di crittografia AES integrate nei processori di iDevices, a cui è possibile accedere solo dalla modalità kernel. I moduli del kernel potrebbero accedervi, ma il codice in quei moduli del kernel dovrebbe anche essere firmato da Apple affinché il kernel li accetti.

Su OS X, dalla versione 10.11 (El Capitan) esiste anche una cosiddetta "modalità rootless" (sebbene il nome sia fuorviante perché root esiste ancora), che proibisce effettivamente a root determinate cose che gli installatori possono ancora fare.
Citando questa eccellente risposta su AskDifferent :

Ecco cosa limita, anche da root:

• Non è possibile modificare nulla in / Sistema, / bin, / sbin o / usr (tranne / usr / local); o una qualsiasi delle app e utility integrate. Solo l'aggiornamento dell'installer e del software possono modificare queste aree, e anche lo fanno solo quando installano pacchetti firmati Apple.

L '"esecuzione del nucleo del sistema" che stai menzionando è ben sotto rootil controllo, ad esempio tramite moduli caricabili del kernel. Naturalmente, questo presuppone che il caricamento dei moduli del kernel sia supportato dal kernel, nessuno può eseguire azioni che non sono fattibili, anche root.

Lo stesso vale per i processi di sistema. rootè autorizzato a interrompere qualsiasi processo, ma è impossibile arrestare un processo in esecuzione nella modalità kernel senza compromettere l'integrità del kernel, quindi è semplicemente impossibile interrompere immediatamente tale elaborazione. Nota che rootnon verrà negato di uccidere quei processi, semplicemente uccidere se stesso non avrà alcun effetto.

Infine, la modalità reale: il kernel Linux non ha supporto per questo, quindi di nuovo nessuno può fare l'impossibile, nemmeno root.

@Siguza ha menzionato l'esecuzione di file senza l' xautorizzazione, il che è abbastanza possibile per l' rootutente:

/lib/ld-linux.so.2 /path/to/executable

Un esempio potrebbe essere la modifica di file di immutabile: È possibile impostare un attributo di file icon chattrche rende il file immutabile anche per root. Per esempio:

# whoami
root
# touch god
# chattr +i god
# rm god
rm: cannot remove ‘god’: Operation not permitted
# touch god
touch: cannot touch ‘god’: Permission denied

Si noti che il file appare come normale file scrivibile ls -lnell'output:

# ls -l god
-rw-r--r-- 1 root root 0 Oct 26 19:27 god

Per vedere l' iattributo, devi usare lsattr:

# lsattr god
----i----------- god

La pagina di manuale di chattr indica quanto segue sull'attributo i:

Un file con l'attributo `i 'non può essere modificato: non può essere cancellato o rinominato, non è possibile creare alcun collegamento a questo file e nessun dato può essere scritto nel file. Solo il superutente o un processo che possiede la capacità CAP_LINUX_IMMUTABLE può impostare o cancellare questo attributo.

Tuttavia, root può facilmente annullare l'immutabilità:

# chattr -i god
# rm -v god
removed ‘god’

Su FreeBSD, non puoi usare gmirrorsu una partizione già montata, anche come root:

gmirror label -v -b preferisce gm0s1 ad4s1
gmirror: impossibile memorizzare i metadati su ad4s1: operazione non consentita.

Devi impostare un sysctl( kern.geom.debugflags=16) per poterlo fare.

rootè un utente privilegiato, ma questi diritti sono dati dal kernel. Quindi il kernel ha più privilegi di root.

Supponendo che la collaborazione da parte dell'utente root stesso, rootpossa essere impedito l'accesso ai supporti FUSE (con le opzioni allow_othero allow_root), ma questo perché FUSE è stato progettato per agire in questo modo. Poiché FUSE risiede su un livello virtuale, può restituire qualsiasi errore che gli piace in base alla logica, al contrario dei moduli di dispositivi a blocchi comuni che si sforzano di essere il più trasparenti e sottili possibile, delegando le autorizzazioni a un altro livello.

Ciò non impedisce all'utente root di disabilitare l'opzione o di sostituire il modulo FUSE con uno che elimina automaticamente l'opzione, a meno che non si renda il file system di sola lettura. Tuttavia, questo porta solo a una situazione di "chi osserva i guardiani": come si può confermare che il sistema non sta mentendo? La tua shell potrebbe anche trovarsi in un chroot che ti mostra un modulo FUSE legittimo, mentre il kernel ne esegue effettivamente una versione malevola.

Direi che l'incapacità di eseguire file non eseguibili è banalmente una limitazione, poiché dipende dalle autorizzazioni dei file. (È possibile aggirare questo problema usando /lib64/ld-linux-x86-64.so.2 per un file non eseguibile, ma non un file su un mount no-exec)

C'è anche il problema dei blocchi obbligatori di file, che impediscono la modifica dei file se un file è attualmente utilizzato da un processo, sebbene il superutente possa terminare il processo.

A un certo punto, il superutente non è stato in grado di smontare un dispositivo mentre il dispositivo era occupato, ma ora è possibile farlo utilizzando un umount pigro.

Altre limitazioni sono:

non può modificare i file immutabili e può solo accodare ai file di sola aggiunta (linux consente al superutente di rimuovere l'immutabile e di aggiungere solo flag a qualsiasi livello di esecuzione, tuttavia, annullandone parzialmente lo scopo)

non è possibile scrivere su un mount di sola lettura o eseguire nulla su un mount no-exec

non è possibile associare un mount non risolvibile

impossibile rimontare un file system come lettura-scrittura se il dispositivo a blocchi è di sola lettura

non è possibile impostare nulla su un supporto per fusibili di proprietà di un altro utente, a meno che non sia montato allow-other o allow-root

non può violare le impostazioni di SELinux

limitazioni intenzionali inerenti al sistema stesso, che influenzano root:

impossibile impostare direttamente il c-time di un file (o l'ora di nascita, se mai implementato)

impossibile visualizzare le password come testo semplice