Perché gli eseguibili in eg / usr / sbin sono scrivibili da root?

Potresti spiegare perché un file compilato binario (ad esempio, /usr/sbin) dispone dell'autorizzazione di scrittura per l' rootutente?

Per me, questo è compilato. Ciò significa che la scrittura diretta non è utile e può esporre il file a qualche problema di sicurezza in qualche modo.

Uno script (ad esempio un bashfile) può essere scrivibile perché è sostanzialmente un file di testo, ma perché è lo stesso per un file compilato in cui nessuna scrittura è effettivamente necessaria per quanto ne so?

Grazie in anticipo per il tuo feedback.

— t1m0th33
fonte

Solo per chiarire, ti stai chiedendo perché l'utente rootha l'autorizzazione di scrittura per un file binario? Se non altro sarebbe utile durante l'aggiornamento di quel pacchetto.

— Eric Renouf,

Nota che i file ironicamente binari sono gli unici file che normalmente scriviamo / modifichiamo direttamente sul disco. Non possiamo farlo con file di testo come gli script perché le modifiche al testo implicano non la scrittura nel file ma l'aggiunta di byte extra nel mezzo del file o l'eliminazione di byte nel mezzo del file. Questo è impossibile da fare con fseek fwrite. Quindi per i file di testo normalmente leggiamo su RAM, quindi eliminiamo il vecchio file e scriviamo il contenuto della RAM su disco (cioè sovrascriviamo). Inoltre, quando installi, sposti o sostituisci file eseguibili, stai scrivendo su disco, quindi hai bisogno delle autorizzazioni di scrittura.

— Slebetman,

@slebetman: puoi modificare direttamente i file di testo. Ad esempio, aprire il file, estenderlo, mapparlo in memoria, utilizzare memmove()per spostare l'ultima parte alla fine e aprire un foro, quindi inserire nuovo testo nel foro. Oppure puoi usare una serie di pread()/ pwrite()per fare lo stesso.

— Zan Lynx,

@EricRenouf In realtà, le autorizzazioni di scrittura sul file binario non sono necessarie per aggiornare il pacchetto che lo contiene. All'aggiornamento del pacchetto, il vecchio binario non viene scritto; in effetti questo è impossibile se il binario è attualmente in esecuzione (cerca ETXTBSY). Al contrario, il vecchio binario viene rimosso e il nuovo binario viene scritto in un nuovo file con lo stesso nome. La rimozione dei file non richiede autorizzazioni di scrittura su di essi, semplicemente sulla directory contenente (cioè, /usr/sbin/).

— marcelm,

@marcelm: A rigor di termini non stai semplicemente usando fseek e scrivi, stai bufferizzando il resto in RAM. Puoi anche salvare il resto in un altro file. Oppure puoi scrivere nuovi contenuti in un nuovo file. Nessuno dei quali consente di estendere i file di testo senza una sorta di buffer di grandi dimensioni.

— Slebetman,

Non importa se i file in /bin(o in qualsiasi altra directory standard in cui sono conservati gli eseguibili) sono scrivibili da root o no. Su un server Linux che sto usando, sono scrivibili per root, ma sulla mia macchina OpenBSD non lo sono.

Finché non sono scrivibili dal gruppo o dagli "altri"!

Non ci sono problemi di sicurezza, ad es

-rwxr-xr-x 1 root root 126584 Feb 18  2016 /bin/ls

Se qualcuno volesse sovrascriverlo, dovrebbero essere root, e se lo sono roote lo sovrascrivono, allora sono

installare una nuova versione, o
goffo, o
un attaccante con permessi di root già .

Un'altra cosa da considerare è che root può scrivere sul file, indipendentemente dal fatto che sia protetto da scrittura o meno, perché ... root.

Notare anche che "uno script" è tanto un eseguibile quanto un file binario. Uno script non deve essere scrivibile "perché è un file di testo". Semmai, dovrebbe avere la stessa autorizzazione degli altri eseguibili nella stessa directory.

Non modificare le autorizzazioni su tutto ora! Ciò può provocare ogni sorta di caos e potenzialmente confondere i gestori di pacchetti che potrebbero verificare che le autorizzazioni siano impostate correttamente. Potrebbe anche rendere vulnerabile il sistema se si modificano accidentalmente le autorizzazioni in modo errato su un'applicazione critica.

Supponi solo che le autorizzazioni sugli eseguibili siano impostate correttamente, a meno che non trovi qualcosa che sembra davvero strano, nel qual caso dovresti probabilmente contattare il responsabile del pacchetto pertinente per verificare piuttosto che iniziare a cambiare roba.

Dai commenti e dalla chat , c'è stata una chiamata per un po 'di storia.

La storia delle autorizzazioni sui binari su Linux non è qualcosa di cui io sappia nulla. Si potrebbe ipotizzare che abbiano semplicemente ereditato i permessi dalla directory, o semplicemente dal default umaskdi Linux, ma davvero non lo so.

Quello che so è che OpenBSD installa i binari nel sistema di base ¹ con modalità di autorizzazione 555 per impostazione predefinita ( -r-xr-xr-x). Questo è specificato in un frammento di Makefile in /usr/share/mk/bsd.own.mkcui è impostato BINMODEsu 555 (a meno che non sia già impostato). Questo viene successivamente utilizzato durante l'installazione degli eseguibili durante make buildin /usr/src.

Ho dato un'occhiata al registro CVS annotato per questo file e ho scoperto che questa riga nel file è rimasta invariata da quando è stata importata da NetBSD nel 1995.

Su NetBSD, il file è stato inserito per la prima volta nel CVS nel 1993, con un valore BINMODEimpostato su 555.

Il progetto FreeBSD sembra aver usato esattamente lo stesso file di NetBSD almeno dal 1994 , e con un commit successivo aggiunge un suggerimento nel messaggio di commit che i vecchi file provenivano dalla versione 4.4BSD di Berkeley Software Distribution.

Oltre a ciò, il CSRG di Berkeley ha conservato le fonti in SCCS ma il loro repository è disponibile in formato Git su GitHub ² . Il dossier che stiamo dando al trattamento forencico qui sembra essere stato commesso da Keith Bostic (o da qualcuno vicino a lui) nel 1990.

Questa è quella storia. Se vuoi il perché , allora suppongo che dovremo chiedere a Keith. Speravo di vedere un messaggio di commit per un cambiamento che dicesse " questo deve essere 555 perché ... ", ma no.

^{1 I} _{sistemi BSD hanno una divisione più rigorosa in "sistema base" e "pacchetti di terze parti" (porte / pacchetti) rispetto a Linux. Il sistema di base è un'unità coerente che fornisce un set completo di funzionalità per l'esecuzione del sistema operativo, mentre le porte o i pacchetti sono visti come "software locale" e sono installati sotto /usr/local.}

² _{Un repository GitHub più completo dei rilasci Unix degli anni '70 in poi è disponibile troppo .}

— Kusalananda
fonte

Grazie per la tua risposta L'autorizzazione alla scrittura è normale in quanto non importa come utente root (può fare qualsiasi cosa). Ma, dato che non importa davvero, perché non mettiamo nessun permesso di scrittura se è lo stesso dall'inizio? È una decisione arbitraria?

— t1m0th33,

@ t1m0th33 Credo che potrebbe essere una decisione arbitraria che qualcuno ha preso, sì. Come ho detto, sul mio sistema OpenBSD, i file in quelle posizioni non sono scrivibili da root.

— Kusalananda

Non penso che sia una decisione consapevole da parte di nessuno. Per impostazione predefinita, il gestore pacchetti installa il file con i bit di autorizzazione con cui sono finiti durante il processo di compilazione; durante la creazione del linker creato i file con autorizzazioni 755 perché è quello che ottieni quando sottrai umask da 777, e la radice umask (sulle macchine build del fornitore del sistema operativo) aveva mentre build era 022 perché 022 è l'umask predefinito per tutti e facendo sarebbe 222 per root sarebbe inutile lavoro extra.

— Henning Makholm,

+1 per "Non modificare le autorizzazioni per tutto adesso!" Vedo tante domande del genere su ASK Ubuntu dove l'utente ha fatto chmod -R su /usro /var, e sorpresa - la loro sudonon funziona o qualcos'altro non funziona.

— Sergiy Kolodyazhnyy,

Storicamente l'assenza del permesso di scrittura per root non avrebbe alcun effetto (root può chmod qualsiasi cosa, e non è nemmeno necessario, perché root non ottiene mai un EPERM su open o comunque). Mi chiedo se queste 555 cose siano iniziate perché in realtà era diventato possibile che il root fosse limitato (quando sono apparsi per la prima volta i