Quali sono le pratiche di sicurezza che utilizzo durante la creazione di una libreria che richiede un accesso root di basso livello a determinati dispositivi e file?

Question

Quali sono le pratiche di sicurezza che utilizzo durante la creazione di una libreria che richiede un accesso root di basso livello a determinati dispositivi e file?

#1 da (3 voti)

3

Backstory

Sto scrivendo una libreria che accede al modulo del kernel, uinput che ti consente di creare o prendere il controllo dei dispositivi in /dev/input/event# e inserire eventi in essi.

Un semplice caso d'uso consentirebbe a qualcuno di scrivere uno script che spostasse il cursore del mouse al centro del display e di eseguire un clic sinistro.

In quanto tale, ha bisogno di privilegi di base per il suo funzionamento, e non sono sicuro di quali rischi tangibili sto prendendo qui, e esattamente quali precauzioni ho bisogno di impiegare.

Ho chiesto informazioni su questo in ##kernel e una risposta che ho ottenuto è stata:

Domande

Èciòchedicevero,chelamiabibliotecaandràbenenellamisuraincuiilmiosistemanonviene"impacchettato"?
A questo proposito, come faccio a sapere che la mia libreria non diventerà un vettore affinché il mio sistema venga "impacchettato"? Non sono un hacker quindi non saprei cosa espone la mia biblioteca a una cosa del genere.
Voglio che il mio codice sia presentabile ai potenziali datori di lavoro, quindi anche se è vero che non ho bisogno di preoccuparmi, quali pratiche di sicurezza dovrei impiegare solo per dimostrare che sono astuto e consapevole dei potenziali rischi per la sicurezza?
Sarebbe una buona pratica in questo caso coinvolgere me creando un utente con un gruppo di permessi speciali che limiti la sua esposizione al sistema?

Grazie.

programming-practices coding-standards security code-security linux-kernel

posta Akiva 13.02.2018 - 21:24

fonte

1 risposta

Leggi altre domande sui tag programming-practices coding-standards security code-security linux-kernel

Modellazione di database. Da molte a molte relazioni. Tabelle di collegamento Ottieni dati di servizio di iterazioni future

score 3 · Answer 1

La prima cosa che devi capire sui rischi introdotti da questo design devi considerare cosa può fare root a cui i normali utenti non possono fare.

Un utente nel gruppo root può fare un gran numero di cose che i normali utenti non possono:

Elimina tutti i file nel sistema operativo - incluso il kernel stesso: rm -rf /
Unità di riformattazione e ripartizione
Avvia e arresta i servizi
Installa e disinstalla applicazioni, incluso il malware
Accedi a tutti i file nelle home directory degli utenti (ad esempio la violazione della privacy)

Certo, le moderne installazioni di Linux richiedono che sudo aumenti i privilegi a root se ci si trova in quel gruppo. Ciò impedisce che errori stupidi distruggano completamente la tua macchina.

Detto questo, se la libreria richiede privilegi intensificati, lo stesso vale per qualsiasi applicazione che la utilizza. Se il processo che utilizza la tua libreria non ha privilegi di root , la tua biblioteca non avrà accesso a uinput . Essenzialmente sembrerà che la tua libreria sia rotta. Non sono a conoscenza di un modo per avere i privilegi escalation per una libreria, ma non per l'applicazione che la chiama.

L'unico modo per aggirare i privilegi elevati per il processo che conosco è quello di separare la libreria in un servizio che viene eseguito con i privilegi appropriati e il pezzo che effettua chiamate a quel servizio. Questo approccio ti consentirà almeno di concedere l'accesso a uinput ma non necessariamente a qualcos'altro. Ciò ti consente di controllare un vettore per l'escalation dei privilegi.

Ho lavorato con alcuni hacker di cappello grigio, che essenzialmente sanno come "pungere" una scatola che al momento non è "pwnata". Anche se il tuo servizio ha accesso solo a uinput , potrebbero comunque avere un giorno di campo dal momento che possono avere il controllo del mouse e della tastiera per controllare indirettamente il tuo sistema.

Prenderò la risposta di quell'utente con un granello di sale molto grande. Mentre la probabilità di un hack può essere bassa, non è zero. Quell'utente è probabilmente fortunato.

Best practice:

Cerca di trovare altri mezzi per fornire la stessa funzionalità senza richiedere privilegi elevati. In caso contrario, continua nell'elenco.
Esercita il principio del privilegio minimo . In altre parole, assicurati di concedere l'accesso solo a ciò di cui hai bisogno e negare attivamente tutto il resto.
Separa il codice che richiede privilegi elevati da eseguire nel proprio processo con il proprio utente
Riduci il più possibile il tempo nel codice escalated
Codice di verifica e test che chiama le API privilegiate in modo più rigoroso rispetto al codice non privilegiato