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?
/paride
Come 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.
