Perché un programma non può utilizzare solo il proprio sistema di accesso ai file system?

Durante l'avvio del sistema, il SO prende il controllo esclusivo di molte operazioni privilegiate e diventa il gatekeeper. La CPU e l'hardware stesso ascolteranno solo il processo fidato (il kernel) a cui sono state date le chiavi del regno. Ciò significa che per fare cose come ottenere l'accesso alla maggior parte delle risorse di sistema, l'applicazione deve richiedere effettivamente questo accesso attraverso il sistema operativo. Il sistema operativo in realtà esegue il comportamento richiesto, non l'applicazione. L'applicazione potrebbe provare a fare richieste dirette all'hardware (che dovrebbe essere specifico dell'hardware), ma poiché non è il kernel, le richieste sarebbero ignorate se tentano di accedere a qualsiasi cosa che sia privilegiata per il kernel.

No, le autorizzazioni del file system vengono applicate dal sistema operativo.

Quando un programma vuole eliminare un file, chiama la funzione unlink () , che trasforma immediatamente il controllo sopra al kernel. Il kernel prima controlla se il file esiste e quindi controlla le autorizzazioni ad esso associate. Se l'utente ha il permesso di cancellare (che in genere significa permesso di scrittura sulla directory contenente il file), il kernel, utilizzando il driver del filesystem, eseguirà tutte le azioni necessarie per rimuovere il file dal disco. Fatto ciò, il controllo viene quindi restituito al programma dell'utente.

Questa distinzione tra le azioni eseguite direttamente dal tuo programma (in genere chiamate "user mode" o "user land") e le azioni eseguite dal kernel per conto dell'utente (in genere chiamate "modalità kernel") sono una caratteristica chiave di tutti i sistemi operativi, non solo di Linux, ed è la base di come vengono applicate le regole del kernel, tra cui separazione dei processi, separazione dei privilegi, segmentazione della memoria e tutto ciò che il kernel è responsabile della fornitura.

Qualsiasi difetto o scappatoia che consentirebbe a un programma di aggirare questa protezione sarebbe considerato una vulnerabilità escalation di privilegi e deve essere corretto per il sistema operativo per essere sicuro da usare. Questi sono sorprendentemente comuni, ma in genere vengono risolti rapidamente una volta scoperti.

Rispetto ai privilegi del filesystem, la cosa che impedisce di scrivere il proprio driver del filesystem per aggirare il driver del filesystem del kernel è il fatto che un utente non ha accesso diretto in lettura o scrittura al disco raw. Questi diritti sono controllati (ancora una volta) dalle autorizzazioni del filesystem.

Sui sistemi Linux e Unix, ci sono una serie di file speciali che rappresentano dispositivi fisici, in genere mantenuti nella directory /dev/ . Ad esempio, /dev/sda rappresenta il primo disco SCSI o SATA su Linux. Su BSD (incluso OSX) è /dev/disk0 .

Leggere o scrivere questi file in realtà leggerà o scriverà direttamente sul disco, saltando il driver del filesystem, ma continuando a passare attraverso il kernel. Poiché questi file hanno le loro autorizzazioni impostate su di loro, gli stessi controlli vengono eseguiti dal kernel prima di consentire l'accesso al dispositivo, quindi la sicurezza rimane intatta.

Se dovessi modificare le autorizzazioni o la proprietà della voce in /dev/ per consentire agli utenti ordinari l'accesso diretto al disco, così facendo creerai una vulnerabilità di escalation dei privilegi (indovinato) .

Su qualsiasi computer non banale (inclusi PC, Mac, smartphone, tablet, persino la maggior parte dei router domestici di fascia bassa, ecc.), il processore può funzionare in due modalità o più: modalità di sistema e modalità utente. Solo il kernel del sistema operativo viene eseguito in modalità di sistema; tutti i programmi vengono eseguiti in modalità utente (anche programmi eseguiti sotto un account amministratore di sistema come root su Unix).

Quando il sistema si avvia, il kernel viene caricato in memoria. Configura la MMU per assicurare che solo il kernel possa accedere alle periferiche hardware, che solo il codice del kernel può influenzare i dati del kernel, e che il codice del kernel può essere eseguito solo attraverso interfacce controllate ( chiamate di sistema ). In questo modo, solo il codice del kernel può accedere all'hardware.

Il kernel non fornisce in alcun modo il codice utente per accedere ai dispositivi di archiviazione o fornisce un modo limitato dalle autorizzazioni per i file. Ad esempio, su Linux e molti altri sistemi Unix, ci sono file speciali nella directory /dev che consentono l'accesso diretto a il disco, ma queste voci hanno permessi che consentono l'accesso solo da root e forse da altri utenti del sistema, non dalle applicazioni eseguite da un utente reale o da un servizio non-core. L'unico modo per i processi non privilegiati di accedere al disco è tramite l'interfaccia del filesystem, che include la gestione dei permessi.

Un programma non può ignorare il filesystem perché non ha modo di convincere il processore a lasciarlo parlare con l'unità disco. Il kernel non lo lascerà.

Per renderlo un po 'più chiaro della risposta di @AJ Henderson, hai due opzioni per leggere / scrivere i dati: una per passare attraverso le funzioni del kernel / sistema, che ovviamente si attengono alla sicurezza della "sandbox". L'altro sarebbe quello di accedere direttamente alla risorsa hardware. È abbastanza facile su * nix - basta fare un ls su / dev / sda1 (o qualunque sia il tuo disco):

# ls -l /dev/disk0s2
brw-r-----  1 root  operator    1,   2  8 Feb 16:31 /dev/disk0s2

(scusate, su un mac qui) Come puoi vedere, il disco è leggibile da chiunque abbia i privilegi di amministratore, ma solo scrivibile da root - così si torna alle autorizzazioni di sistema. E per quanto riguarda l'accesso diretto all'hardware, di nuovo questo è limitato alle autorizzazioni a livello di kernel.

Quello che stai descrivendo suona come l' attacco pt_chown descritto a NullCon la scorsa settimana . L'attacco può essere usato per prendere il controllo dei terminali psuedo (ptys) incluso un root (uid = 0) di proprietà pty, che porterebbe all'escalation dei privilegi su una piattaforma Unix. La piattaforma testata e verificata era Linux, ma abbiamo ipotizzato che potesse accadere a OS X o ad un altro sistema operativo BSD.

L'attacco si basava su un filesystem userspace, FUSE .