Il 01/02/23 15:56, Paride Desimone ha scritto:
Il 01-02-2023 12:33 Paride Desimone ha scritto:Buongiorno. Sto provando a studiare Selinux, perché mi serve per un esame di certificazione rhcsa ex200. Qualcuno può dipanarmi un dubbio? Se io confino l'utente root, in modo che nemmeno lui abbia poteri illimitati, in modo che un'eventuale escalation, non consenta di prendere il controllo della macchina, come si fa in caso si voglia agire sulla configurazione di selinux e nemmeno lui può farlo? /parideCome non detto. Non ero arrivato alla gestione degli utenti con selinux. /paride
Ciao Paride,è possibile confinare l'utente root? Io so che prima viene valutata la DAC. Se la DAC permette all'utente di eseguire una certa operazione SELinux non entra in gioco. Se la DAC non lo consente, Selinux controlla tutte le sue cose (contesti, booleans, [attento alle don't audit rules], ecc) (ed è qui che salva le chiappe) e in base alle policy crea un deny o un allow.
Detto questo, essendo root utente con privilegi elevati, è possibile confinarlo?
Inoltre non sarebbe il caso di evitare di far entrare root nel confinamento? Cioè ha senso confinare root? Almeno un utente privilegiato deve poter fare qualcosa se le cose non funzionano, anche perche se tu non permetti a root di effettuare qualcosa tipo operazioni di rete, accesso a determinati file ecc, si può sempre impostare selinux in permissive mode, e poi da quello che ho letto (non l'ho provato) sistemi come SELinux e AppArmor possono essere aggirati a livello del kernel, non chiedermi come che non lo so.
SELinux non dovrebbe evitare proprio problemi di questo tipo come le escalation? (Lo chiedo perche ho il dubbio)
Cmq se puo esserti di aiuto, che nessuno me ne voglia, l'ambiente migliore per studiare SELinux è una RHEL Based tipo AlmaLinux/RockyLinux. Purtroppo su debian ho sempre avuto problemi con SELinux. D'altro canto su debian uso apparmor che nella creazione delle policy è moltooo più semplice e diretto.
Se posso darti un consiglio su SELinux, quando passi al processo della creazione delle policy custom, revisiona sempre quello che audit2allow aggiunge al file della policy (prima di compilarla e caricarla) perche potrebbe includere software/contesti/azioni che non vorresti permettere e questo è male perche crei una policy bacata non sapendolo.
Altro consiglio è, nel caso in cui non riesci a trovare il deny ad una certa azione e quindi non puoi creare la regola nella policy, ti può tornare utile disabilitare le regole dont'audit che sono regole per cui è indicato di non riportate negli audit perche ce ne sarebbero troppe nel log. A me è capitato con un'applicazione che provava ad accedere a PostgreSQL ma l'applicazione nel contesto non aveva il permesso di lettura e scrittura nel comunicare in rete con postgresql. Ci ho messo qualche giorno per scoprire queste tipi di regole.
Un saluto e scusate l'OT.