Is it a bad idea per se
È una cattiva idea discriminare l'immagine del processo e ti aspetti di ottenere un qualche tipo di sicurezza, se non proteggi questi processi.
Lista bianca immagine eseguibile
Ad esempio, supponi di consentire solo wget e arricciare e bloccare tutti gli altri accessi alla rete. Potresti pensare che questa impostazione di sicurezza permetta richieste arbitrarie di HTTP / s, FTP, ecc., Ma non invii dati arbitrari via TCP, o lanci arbitrari di server TCP o usi UDP. Ma poiché wget e arricciatura sono normali programmi non impostati in modo dinamico collegati a qualcosa, possono essere:
- iniziato con arbitrario
LD_LIBRARY_PATH
, avviato con un caricatore dinamico modificato, qualsiasi trucco ltrace fa
- tracciato, come
strace
- modificato in fase di esecuzione con
ptrace
(2)
Come strace
/ ltrace
do, puoi manipolare qualsiasi processo a meno che non venga eseguito con un ID utente o gruppo diverso o con capacità che non hai.
Se si desidera associare qualsiasi diritto specifico a immagini specifiche (ad esempio /usr/bin/wget
), è necessario proteggere i processi lanciati da interferenze con la stessa severità con cui i processi set-set sono protetti. A meno che non sia fatto correttamente, per lo più disponi di sistemi di sicurezza e protezione da minacce non adattive (che è forse tutto ciò che ti serve, ma dovresti dire esplicitamente).
Ovviamente puoi proteggere un processo solo se è progettato per essere protetto dal suo utente e la maggior parte dei programmi no. In particolare la maggior parte dei browser consente l'installazione di estensioni arbitrarie cui è consentito accedere alla rete, tutto dal processo del browser, con i diritti del processo, a volte senza alcuna restrizione di sicurezza specifica, quindi si dovrebbe anche impedire l'installazione di estensioni nei programmi autorizzati .
Lista nera delle immagini eseguibili
OTOH, puoi usare il firewall per impedire a demoni specifici di accedere alla rete o aprire connessioni impreviste.
Per applicare queste restrizioni, è necessario almeno:
- impedisce ai processi con restrizioni di avviare processi illimitati
- impedisce ai processi limitati di interferire (come sopra) con processi illimitati
L'avvio di immagini eseguibili arbitrarie viene eseguito con exec
e il kernel deve impedire ai processi limitati di avviare immagini senza restrizioni o taggare il nuovo processo in modo che sia limitato come i suoi genitori.
Un'immagine eseguibile può anche essere eseguita indirettamente aggiungendo cron
/ anacron
/ at
/ batch
jobs, quindi è necessario impedire che il processo limitato modifichi gli elenchi di lavoro, assicurandosi che non lo facciano possiede i file degli elenchi dei lavori e non ha accesso in scrittura a tali file. Qualsiasi utente potrebbe anche procmailrc ed eseguire comandi arbitrari ogni volta che viene ricevuta la posta, ecc.
Queste restrizioni devono essere integrate a livello di OS, non solo a livello di kernel. Questo va contro la tradizione Unix in cui è previsto che ogni processo con un ID utente abbia la possibilità di avviare qualsiasi processo con il suo user-ID, e il cron
/ at
/ maildrop DAEMON / programmi hanno integrato questa ipotesi. Devi cercare un demone che avvii programmi per conto di un utente e mettere in blacklist queste funzionalità.
Vedi lo schema? L'applicazione di una blacklist di processi specifici che impediscono chiamate di sistema specifiche (accesso alla rete) porta a più backlist non solo su altre chiamate di sistema ( exec
family) ma anche su altri componenti del sistema operativo. Qualsiasi secure, Unix- ragionevole (ovvero: il cui comportamento è completamente previsto in un sistema Unix tradizionale) DAEMON può introdurre una scappatoia di sicurezza.
Conclusione
Il "kernel" del kernel (la parte di micro-kernel di un kernel monolitico) deve conoscere i diritti di processo, non solo un sottosistema specifico (sottosistema di rete, file system, ecc.). Il "diritto alla rete" è una proprietà essenziale di un processo, proprio come gli ID utente o il set di funzionalità.
Oppure puoi dire che tutto ciò di cui hai bisogno è una protezione da minacce non adattive: hai paura di worm / virus standard, non di attacchi mirati.
Questo è un problema generale in qualsiasi funzione di sicurezza retrofittata.
Conclusioni personali
Questo è il motivo per cui penso che le capacità siano fondamentalmente un'idea terribilmente infranta. Unix si basa sull'ID utente: se si desidera l'isolamento della sicurezza, utilizzare un UID diverso. Questa risorsa è economica.