Il superutente può scrivere in file di sola lettura?

Mi sono imbattuto nel sorprendente (per me) comportamento dei permessi su FreeBSD. Diciamo che sto operando come utente non root . Creo un file, imposto la sua autorizzazione in sola lettura e quindi provo a scriverlo:

$ touch f
$ chmod 400 f
$ ls -l f
-r--------  1 user  wheel  f
$ echo a >> t
t: Permission denied.

Fin qui tutto bene. Ora faccio lo stesso di root e scrive nel file:

# ls -l f2
-r--------  1 root  wheel  f2
# echo a >> f2
# echo $?
0

È un bug o un comportamento previsto? Posso tranquillamente supporre che questo funzionerebbe così su qualsiasi Unix e Linux?

files permissions root

— arrowd
fonte

Qualsiasi utente con CAP_DAC_OVERRIDEpuò farlo. Su quasi tutti i sistemi Linux ciò significa che root può farlo, quindi è intenzionale. Non posso parlare per la parte di FreeBSD ma immagino che abbiano una configurazione simile.

— Bratchley,

Il motivo per cui la radice deve SEMPRE essere in grado di scrivere su un file è perché sui file system unix tradizionali (ext4, zfs ecc.) Le autorizzazioni per i file fanno parte del file. Pertanto, se root non è in grado di scrivere su un file, NOBODY può rendere nuovamente scrivibile il file di sola lettura perché chmodnon è possibile scrivere sul file.

— Slebetman,

@slebetman Non è necessario disporre dell'accesso in scrittura a un file per aggiornare le autorizzazioni. Prova touch somefile; chmod 0000 somefile; chmod 0644 somefilecome un normale utente.

— user253751

@immibis: che possiedi. Il root deve poter cambiare i permessi sui file che non possiede

— slebetman il

@slebetman Sì ... ma stavi parlando di cambiare i permessi sui file sui quali non puoi scrivere, non di cambiare i permessi sui file che non possiedi.

— user253751

Risposte:

È normale rootpoter sovrascrivere le autorizzazioni in questo modo.

Un altro esempio è la rootpossibilità di leggere un file senza accesso in lettura:

$ echo hello > tst
$ chmod 0 tst
$ ls -l tst
---------- 1 sweh sweh 6 Aug 16 15:46 tst
$ cat tst
cat: tst: Permission denied
$ sudo cat tst
hello

Alcuni sistemi hanno il concetto di file immutabili . ad es. su FreeBSD:

# ls -l tst
-rw-r--r--  1 sweh  sweh  6 Aug 16 15:50 tst
# chflags simmutable tst
# echo there >> tst
tst: Operation not permitted.

Ora rootnon riesco nemmeno a scrivere nel file. Ma, ovviamente, rootpuoi rimuovere la bandiera:

# chflags nosimmutable tst
# echo there >> tst
# cat tst
hello
there

Con FreeBSD puoi fare un ulteriore passo avanti e impostare un flag del kernel per impedire rootdi rimuovere il flag:

# chflags simmutable tst
# sysctl kern.securelevel=1
kern.securelevel: -1 -> 1
# chflags nosimmutable tst
chflags: tst: Operation not permitted

Ora nessuno, nemmeno rootpuò cambiare questo file.

(Il sistema deve essere riavviato per ridurre la sicurezza).

— Stephen Harris
fonte

In che modo è necessario riavviare una misura di sicurezza efficace? Inoltre, se root è root e può fare qualsiasi cosa, perché anche preoccuparsi di provare a impedire a root di fare ciò che root vuole?

— gatto

Su un sistema sicuro, root non è simile a Dio. FreeBSD securelevel è un piccolo tentativo di rendere root meno simile a Dio. Securelevel può essere impostato sul valore predefinito 1 nella configurazione del sistema in modo che rimanga attivo anche dopo un riavvio. Quindi avrebbe bisogno dell'accesso alla console e della modalità utente singolo ed è molto evidente. C'è un intero saggio sulla sicurezza di Unix che è troppo per un campo di commento SE, ma stiamo provando a passare da un modello "root access to access" a qualcosa di più sfumato. Cerchiamo di applicare laddove possibile (ad es. Securelevel) e di rilevare dove no (riavvia prove, audit trail).

— Stephen Harris,

FWIW, in Linux chattr +i tstimposta l' attributo immutabile .

— Ruslan,

Sì, questo è molto normale. root non ha limiti di lettura / scrittura (con pochissima eccezione), perché è il root.

— Ipor Sircer
fonte