Perché l'utente senza privilegi non può cambiare la proprietà dei file?


15

Da chown (2):

Solo un processo privilegiato (Linux: uno con la capacità CAP_CHOWN) può cambiare il proprietario di un file. Il proprietario di un file può modificare il gruppo del file in qualsiasi gruppo di cui quel proprietario è membro. Un processo privilegiato (Linux: con CAP_CHOWN) può modificare il gruppo in modo arbitrario.

Qual è la ragione di questa restrizione? Perché un utente non privilegiato non può cambiare la proprietà del file di un file di sua proprietà (es. No / etc / shadow)?

$ touch blah
$ chown root:root blah
chown: changing ownership of `blah': Operation not permitted

Risposte:


27

Consentendo agli utenti di "regalare" file si esegue una violazione di varie funzionalità del sistema operativo. Ad esempio:

Taking up another user's disk quota.
Impersonating another user (or even root) via setuid.
Having insufficient privileges to undo a mistaken chown.
Making it appear that someone else had created a given file.
Setting up cron jobs to run on other user's accounts.
And many more...

8

È solo una scelta personale dei progettisti di Linux non consentirlo - tutti i motivi di pseudo-sicurezza, dati , sono speciosi, poiché ci sono sistemi unix che lo consentono.

Penso che questa funzionalità sia dovuta al fatto che il comportamento del tuo unix seguisse o meno "System-V" (AT&T) o Berixeley unix (BSD) ...

Per quanto riguarda gli altri problemi di sicurezza menzionati:

  • Impersonare un altro utente (o persino root) tramite setuid.

    Nessun problema: la modifica di "proprietario" cancella tutti i bit "setXid" (U / G)

  • Avere privilegi insufficienti per annullare un abito sbagliato

    Non proprio un "rischio per la sicurezza", MA potrebbe essere sui sistemi che consentono di cambiare utente, puoi cambiarlo nuovamente se si trova in una directory di tua proprietà, altro che saggio: "stai attento"!

  • Far sembrare che qualcun altro avesse creato un determinato file.

    Sarebbe ancora in una directory che è scrivibile da te. Vale a dire che non potresti spostarlo nel loro homedir, a meno che non sia aperto per la scrittura nel tuo gruppo o tutti (o in particolare se gli ACL sono disponibili).

  • Impostazione dei lavori cron per l'esecuzione su account di altri utenti.

    Ancora una volta, non funzionerebbe - dal momento che i conduttori sono di proprietà dell'utente e non sono impostati per essere leggibili da altri utenti, figuriamoci scrivibili.

  • se qualcuno potesse cambiare la proprietà, allora chiunque potrebbe cambiare le autorizzazioni per ottenere l'accesso a qualsiasi file sul sistema.

    No: solo se l'utente "possiede" la directory contenente quel file. Vale a dire che posso dare un file chiamato 'passwd' a root, ma non posso spostarlo in / etc / a meno che non abbia il permesso di scrivere in / etc /.

  • quote

    Un punto potenzialmente valido - SE usi le quote, ma sembra che sarebbe facile rilevare se riassumi lo spazio su disco per home-dir; L'unico problema sarebbe nelle directory che sono scrivibili da più utenti. Nel qual caso, magari andando dal proprietario di quella 'dir'. E PUÒ essere il caso su quei sistemi che supportano 'regalando' file, che si può fare solo in directory in cui si 'proprio', ma è stato MOLTO tempo da quando sono stato effettivamente su un sistema che permette questo, in modo da Non ricordo le restrizioni esatte.

Mi sembra di ricordare che ci sia stato un "compromesso" per consentire il "dare via i file" ... ad esempio - sui sistemi che lo permettevano, qualcos'altro non era permesso che linux lo permettesse, ma non ricordo cosa era spento mano...

Direi che la 'risposta' sopra dovrebbe essere contrassegnata come la risposta, in quanto NON è la vera risposta. È più una decisione di progettazione - semplicemente non so quali fossero i compromessi.

Potrebbero esserci problemi di sicurezza non sollevati sopra che potrebbero essere problemi validi, ma quelli sopra non sono validi.

IMO, dovrebbe essere un "valore" impostabile dal sistema in "/ proc", ma in generale, penso che alla maggior parte delle persone non importi molto.

Se fosse fortemente necessario, 'chown' potrebbe essere migliorato per la sicurezza e modificato per consentirlo e quindi impostare w / setuid 'root' per consentirgli di implementare tale politica.


Le quote si basano sempre sulla proprietà del file , non sulla posizione . Altrimenti qualcuno potrebbe tenere tutto dentro /tmp.
user1686

+1, sembri dannatamente giusto :). Sui sistemi OpenSolaris (che è in effetti un discendente di System V) è possibile impostare questo tramite mountun'opzione (questa impostazione può quindi essere limitata a un singolo punto di montaggio anziché essere a livello di sistema secondo il suggerimento di valore impostabile dal sistema): rstchown(impostazione predefinita ) per limitare le modifiche del proprietario del file all'utente root, norstchownper consentire agli utenti non privilegiati di modificare il proprietario dei propri file (non è possibile modificarlo nuovamente).
WhiteWinterWolf

6

Bene, se qualcuno potesse cambiare la proprietà, allora chiunque potrebbe cambiare le autorizzazioni per ottenere l'accesso a qualsiasi file sul sistema. Questo non è male solo dal punto di vista del malware (non è richiesto il sudo), ma dal punto di vista di un amministratore di sistema. Se uno qualsiasi degli utenti è in grado di modificare uno qualsiasi dei file, le autorizzazioni per i file sono inutili.


2
Giusto. Ho modificato la domanda per chiarire che mi riferivo ai file di proprietà dell'utente e non a nessun file.
Alexandru,

1
@Alexandru: pensa a un utente malintenzionato che cambia myTrojan.shproprietà e che ha un flag SUID.
Benjamin Bannier,

@honk: ha un senso adesso.
Alexandru,

5

Perché allora l'utente può eludere le quote del filesystem. Se ho una quota di 100 MB e hai una quota di 100 MB, posso caricare 100 MB, chmod a + r, chown te, quindi caricare altri 100 MB.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.