Un processo eseguito come root ha un accesso più ampio a varie chiamate di sistema, che aumenta la superficie di attacco. Anche se SELinux è correttamente applicato, ci sarà ancora un rischio maggiore di sfruttamento del kernel. Il motivo è che molte chiamate di sistema hanno controlli per garantire che il processo sia eseguito come root (in particolare, i controlli sono in genere per CAP_SYS_ADMIN ). Se il processo è privo di tali autorizzazioni, restituisce rapidamente EPERM o un errore simile. Se ha queste autorizzazioni, un bug tra il controllo rapido delle autorizzazioni e i controlli LSM molto successivi può consentire a un processo di sfruttare il kernel e disabilitare SELinux o altro.
Un processo privilegiato può essere in grado di intraprendere azioni che SELinux non può limitare a causa del fatto che non esiste alcun hook di LSM , a cui i controlli di accesso obbligatori tendono a fare affidamento. Questi hook sono sparsi in tutto il kernel e, ogni volta che vengono raggiunti, controllano se l'LSM ha limitato o meno l'azione. Ad esempio, dopo i controlli DAC (permessi Unix standard), esiste un hook LSM che controlla se è consentito o meno l'accesso a un determinato oggetto filesystem. Poiché il kernel è così complesso e ha una relazione così estesa con userspace, non è possibile limitare tutto. Per un esempio, la rischiosa chiamata di sistema ioctl (un syscall catch-all contro descrittori di file che consente ai driver del kernel di registrare ciò che è in effetti le proprie chiamate di sistema) non è limitata da SELinux. Per fornire restrizioni più dettagliate, è necessario autorizzare le singole syscalls e i relativi argomenti. Questo può essere fatto usando il seccomp filtro syscall.
Non importa quanto tu pensi che la tua politica SELinux sia ristretta, c'è sempre spazio per miglioramenti. Ad esempio, limita il processo " limiti di risorse ? I processi di root sono in grado di ignorare i limiti di risorse, che possono avere implicazioni sulla sicurezza (ad esempio, è possibile disabilitare ASLR per i processi appena eseguiti se si è in grado di controllare i limiti delle risorse dello stack).
Nel complesso, ci sono quattro rischi principali che posso pensare quando si esegue un processo come root:
-
Come spiegato sopra, l'area di superficie di attacco aumentata può essere sfruttabile.
-
La mancanza di difesa in profondità significherà che un bug in SELinux potrebbe portare allo sfruttamento.
-
SELinux non è in grado di agganciare ogni possibile azione che un processo di root può eseguire.
-
Indipendentemente dalla rigidità della norma, può sempre essere migliorata (ad es. limita i rlimits?)
A meno che non sia proibitivamente difficile eseguire il demone come proprio utente, suggerirei di eliminare i privilegi in modo appropriato come se non si stesse usando affatto un sistema di controllo accessi.