[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian 11 e SELinux




Il 11/08/21 14:53, Alessandro Baggi ha scritto:
Il 11/08/21 13:48, Alessandro Baggi ha scritto:
Un saluto a tutta la lista.

Ho installato su una macchina virtuale KVM Debian 11 (non ancora rilasciata) e ho attivato SELinux. Come riportato su https://wiki.debian.org/SELinux/Setup ho rimosso AppArmor e installato selinux-basics selinux-policy-default e auditd, ho lanciato selinux-activate e ho riavviato. Il sistema, giustamente, ha effettuato un relabel di tutto. Successivamente ho modificato la configurazione di SELinux da permissive a enforcing.

Il problema è che non mi permette di loggarmi via ssh con utente normale dandomi come errore:

/bin/bash: permission denied

Ho usato SELinux su distro della famiglia RPM ma non sono esperto in quanto ho solo configurato dei contesti, qualche boolean e confinato qualche user e non riesco a capire come risolvere questo problema.

Ho provato ad assegnare ad un utente il ruolo user_u con "usermod -Z user_u username" e riesco ad effettuare il login via ssh ma ho notato che lanciando "su -" non mi permette di leggere/scrivere file che sono soggetti ad altri contesti, come se l'utente root fosse confinato. Questa cosa non accade però se il login viene effettuato da console. Purtroppo la documentazione di Debian non mi è di alcun aiuto.

In rete non sono riuscito a trovare granchè ma solo problemi relativi ad anni dimenticati

Qualcuno ha qualche suggerimento?

Grazie in anticipo.

Dopo aver spulciato qualche boolean di SELinux ho abilitato ssh_sysadm_login (impostato a on) e permette agli utenti non confinati di effettuare il login su ssh.

Non capisco perche se effettuo il login da utente confinato se lancio id -Z ho:

    user_u:user_r:user_t:s0

e dopo "su - root" mantiene lo stesso contesto dell'utente semplice e non unconfined. Può essere che la transazione da un contesto user_t non puo essere effettuata verso unconfined?


Continuando la ricerca ho capito che: se si necessità di avere solo i servizi pubblicati su internet come confinati non ha senso usare il mapping degli user con gli user SELinux. Inoltre se viene abilitato il boolean ssh_sysadm_login, agli utenti non confinati è permesso il login, mentre ad un utente lo confiniamo con "user_u", è permesso il login ssh ma è confinato quindi nel caso in cui lanciasse un "su -" e ottenesse la root ha comunque il contesto dell'utente confinato e quindi non può fare nulla.

Quello che  non mi è chiaro è che se un utente lo mappo all'user SELinux staff_u (dalla doc di gentoo: SELinux user with direct system administrative role assigned), permette di fare il login ma non permette di lanciare comandi amministrativi ne da utente normale (credo sia normale) ne da utente root (con su -) perche il contesto rimane lo stesso di staff_u. A questo punto a che serve se non puo lanciare comandi amministrativi tipo apt?


Reply to: