newrole -r rol_r -t domini_t (normalment només hi ha un sol domini permès per a un rol donat, així doncs el paràmetre -t sovint es pot obviar). Aquesta ordre autentica l'usuari demanant la contrasenya. Aquesta característica impedeix que els programes canviïn automàticament els rols. Aquests canvis només poden ocórrer si estan explícitament permesos en la política de SELinux.
ssh està etiquetat amb ssh_exec_t, i quan el programa inicia, es canvia automàticament al domini ssh_t). Aquest mecanisme automàtic de transició de domini permet concedir només els drets requerits per cada programa. És un principi fonamental de SELinux.
apt install selinux-basics selinux-policy-default auditd instal·larà automàticament els paquets necessaris per configurar un sistema SELinux.
unconfined (la gestió de mòduls és detallarà més endavant en aquesta secció).
fixfiles relabel.
selinux=1 security=selinux al nucli de Linux. El paràmetre audit=1 permet el registre de SELinux que registra totes les operacions denegades. Finalment, el paràmetre enforcing=1 comporta l'aplicació de les regles: sense ell SELinux funciona en el seu mode per defecte «permissive» on les accions denegades estan registrades però tot i així executades. Per tant, s'hauria de modificar el fitxer de configuració del gestor d'arrencada GRUB per afegir els paràmetres desitjats. Una manera fàcil de fer-ho és modificar la variable GRUB_CMDLINE_LINUX a /etc/default/grub i executar update-grub. SELinux estarà actiu després d'un reinici.
selinux-activate automatitza aquestes operacions i obliga a etiquetar en la següent arrencada (fet que evita nous fitxers no etiquetats creats mentre SELinux encara no estava actiu i mentre l'etiquetatge estava en curs).
semodule. A més, heu de poder definir els rols que cada usuari pot adoptar, i això es pot fer amb l'ordre semanage.
/etc/selinux/default/. A diferència d'altres fitxers de configuració que es poden trobar a /etc/, tots aquests fitxers no s'han de canviar manualment. S'haurien d'utilitzar els programes dissenyats per a aquest propòsit.
/usr/share/selinux/default/. Per habilitar un d'aquests mòduls en la configuració actual, s'hauria d'utilitzar semodule -i mòdul.pp.bz2. L'extensió pp.bz2 significa «policy package» o “paquet de polítiques” (comprimit amb bzip2).
semodule -r mòdul. Finalment, l'ordre semodule -l llista els mòduls que estan instal·lats actualment. També en mostra els números de versió. Els mòduls es poden activar de manera selectiva amb semodule -e i desactivar amb semodule -d.
#semodule -i /usr/share/selinux/default/abrt.pp.bz2libsemanage.semanage_direct_install_info: abrt module will be disabled after install as there is a disabled instance of this module present in the system. #semodule -laccountsd acct [...]#semodule -e abrt#semodule -d accountsd#semodule -labrt acct [...]#semodule -r abrtlibsemanage.semanage_direct_remove_key: abrt module at priority 100 is now active.
semodule carrega immediatament la nova configuració llevat que afegiu l'opció -n. Val la pena assenyalar que el programa actua per defecte amb la configuració actual (indicada per la variable SELINUXTYPE a /etc/selinux/config), però que se'n pot modificar una altra especificant-la amb l'opció -s.
semanage.
-a per afegir, -d per suprimir, -m per modificar, -l per llistar, i -t per indicar un tipus (o domini).
semanage login -l llista la relació actual entre els identificadors d'usuari i les identitats de SELinux. Els usuaris que no tenen una entrada explícita obtenen la identitat indicada a l'entrada __default__. L'ordre semanage login -a -s user_u usuari associarà la identitat user_u a l'usuari indicat. Finalment, semanage login -d usuari elimina l'entrada de relació assignada a aquest usuari.
#semanage login -a -s user_u rhertzog#semanage login -lLogin Name SELinux User MLS/MCS Range Service __default__ unconfined_u s0-s0:c0.c1023 * rhertzog user_u s0 * root unconfined_u s0-s0:c0.c1023 * #semanage login -d rhertzog
semanage user -l llista les relacions entre les identitats d'usuari de SELinux i els rols permesos. Afegir una nova identitat requereix definir els rols corresponents i un prefix d'etiquetatge que s'utilitza per assignar un tipus a fitxers personals (/home/usuari/*). El prefix ha de ser triat entre user, staff, i sysadm. El prefix «staff» dona com a resultat fitxers de tipus «staff_home_dir_t». La creació d'una nova identitat d'usuari de SELinux es fa amb semanage user -a -R rols -P prefixe identitat. Finalment, es pot eliminar una identitat d'usuari de SELinux amb semanage user -d identitat.
#semanage user -a -R 'staff_r user_r' -P staff test_u#semanage user -lLabeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles root sysadm s0 s0-s0:c0.c1023 staff_r sysadm_r system_r staff_u staff s0 s0-s0:c0.c1023 staff_r sysadm_r sysadm_u sysadm s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r test_u staff s0 s0 staff_r user_r unconfined_u unconfined s0 s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0 user_r #semanage user -d test_u
/srv/www/, es pot executar semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?" seguit de restorecon -R /srv/www/. La primera ordre registra les noves regles d'etiquetatge i l'última reinicia els tipus de fitxers d'acord amb les regles d'etiquetatge actuals.
semanage port -m -t http_port_t -p tcp 8080.
getsebool es pot utilitzar per inspeccionar aquestes opcions (getsebool booleà mostra una opció, i getsebool -a totes). L'ordre setsebool booleà valor canvia el valor actual d'una opció booleana. L'opció -P fa que el canvi sigui permanent, que significa que el nou valor es converteix en el valor per defecte i es mantindrà després de reiniciar. L'exemple següent concedeix als servidors web un accés als directoris d'usuari (això és útil quan els usuaris tenen llocs web personals a ~/public_html/).
#getsebool httpd_enable_homedirshttpd_enable_homedirs --> off #setsebool -P httpd_enable_homedirs on#getsebool httpd_enable_homedirshttpd_enable_homedirs --> on
/usr/share/doc/selinux-policy-doc/html/) i fitxers de mostra que es poden utilitzar com a patró per crear nous mòduls. Instal·leu aquests fitxers i estudieu-los més de prop:
$cp /usr/share/doc/selinux-policy-doc/Makefile.example Makefile$cp /usr/share/doc/selinux-policy-doc/example.fc ./$cp /usr/share/doc/selinux-policy-doc/example.if ./$cp /usr/share/doc/selinux-policy-doc/example.te ./
.te és el més important. Defineix les regles. El fitxer .fc defineix els "contextos de fitxers", és a dir, els tipus assignats als fitxers relacionats amb aquest mòdul. Les dades del fitxer .fc s'utilitzen durant el pas de l'etiquetatge de fitxers. Finalment, el fitxer .if defineix la interfície del mòdul: és un conjunt de "funcions públiques" que altres mòduls poden utilitzar per interaccionar correctament amb el mòdul que esteu creant.
myapp_domtrans”) controla qui pot executar l'aplicació. El segon (“myapp_read_log”) concedeix drets de lectura als fitxers de registre de l'aplicació.
.te. Per tant, cal declarar tots els tipus que utilitzeu (amb la macro gen_require), i utilitzar directives estàndard per concedir drets. No obstant això, cal tenir en compte que es poden utilitzar interfícies proporcionades per altres mòduls. La següent secció donarà més explicacions sobre com expressar aquests drets.
Exemple 14.3. El fitxer example.if
## <summary>Myapp example policy</summary>
## <desc>
## <p>
## More descriptive text about myapp. The desc
## tag can also use p, ul, and ol
## html tags for formatting.
## </p>
## <p>
## This policy supports the following myapp features:
## <ul>
## <li>Feature A</li>
## <li>Feature B</li>
## <li>Feature C</li>
## </ul>
## </p>
## </desc>
#
########################################
## <summary>
## Execute a domain transition to run myapp.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed to transition.
## </summary>
## </param>
#
interface(`myapp_domtrans',`
gen_require(`
type myapp_t, myapp_exec_t;
')
domtrans_pattern($1,myapp_exec_t,myapp_t)
')
########################################
## <summary>
## Read myapp log files.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed to read the log files.
## </summary>
## </param>
#
interface(`myapp_read_log',`
gen_require(`
type myapp_log_t;
')
logging_search_logs($1)
allow $1 myapp_log_t:file read_file_perms;
')
example.te:
policy_module(example,1.0.0)# a non-base module name must match the file name ######################################## # # Declarations # type myapp_t;
type myapp_exec_t; domain_type(myapp_t) domain_entry_file(myapp_t, myapp_exec_t)
type myapp_log_t; logging_log_file(myapp_log_t)
type myapp_tmp_t; files_tmp_file(myapp_tmp_t) ######################################## # # Myapp local policy # allow myapp_t myapp_log_t:file { read_file_perms append_file_perms };
allow myapp_t myapp_tmp_t:file manage_file_perms; files_tmp_filetrans(myapp_t,myapp_tmp_t,file)
|
El mòdul s'ha d'identificar pel seu nom i el número de versió. Aquesta directiva és necessària.
|
|
Si el mòdul introdueix nous tipus, ha de declarar-los amb directives com aquesta. No s'ha de dubtar per crear tants tipus com siguin necessaris en lloc de concedir massa drets inútils.
|
|
Aquestes interfícies defineixen el tipus myapp_t com un domini de procés que hauria d'utilitzar qualsevol executable etiquetat amb myapp_exec_t. Implícitament, això afegeix un atribut exec_type en aquests objectes, que al seu torn permet a altres mòduls concedir drets per executar aquests programes: per exemple, el mòdul userdomain permet processos amb dominis user_t, staff_t, i sysadm_t per executar-los. Els dominis d'altres aplicacions confinades no tindran els drets per executar-les, tret que les normes els concedeixin drets similars (aquest és el cas, per exemple, de dpkg amb el seu domini dpkg_t).
|
| logging_log_file és una interfície proporcionada per la política de referència. Indica que els fitxers etiquetats amb el tipus donat són fitxers de registre que haurien de beneficiar-se de les regles associades (per exemple, concedint drets a logrotate perquè pugui manipular-los).
|
|
La directiva allow és la directiva base utilitzada per autoritzar una operació. El primer paràmetre és el domini de procés que està autoritzat per executar l'operació. El segon defineix l'objecte que un procés del domini anterior pot manipular. Aquest paràmetre és de la forma “tipus:classe” on tipus és el seu tipus SELinux i classe descriu la naturalesa de l'objecte (fitxer, directori, sòcol, «fifo», etc.). Finalment, l'últim paràmetre descriu els permisos (les operacions permeses).
Els permisos es defineixen com el conjunt d'operacions permeses i segueixen aquesta plantilla: { operació1 operació2 }. No obstant això, també es poden utilitzar macros que representin els permisos més útils. El fitxer /usr/share/selinux/devel/include/support/obj_perm_sets.spt els llista.
La pàgina web següent proporciona una llista relativament exhaustiva de classes d'objectes, i de permisos que es poden concedir.
|
avc: denied { read write } for pid=1876 comm="syslogd" name="xconsole" dev=tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=fifo_file permissive=1Taula 14.1. Anàlisi d'una traça de SELinux
| Missatge | Descripció |
|---|---|
avc: denied | S'ha denegat una operació. |
{ read write } | Aquesta operació requeria els permisos read i write. |
pid=1876 | El procés amb el PID 1876 va executar l'operació (o ho va intentar). |
comm="syslogd" | El procés era una instància del programa syslogd. |
name="xconsole" | L'objecte de destinació s'anomenava xconsole. A vegades també es pot tenir una variable «path», amb el camí complet, en lloc seu. |
dev=tmpfs | El dispositiu que alberga l'objecte de destinació és un tmpfs (un sistema de fitxers en memòria). Per a un disc real, es podria veure la partició que allotjava l'objecte (per exemple, «sda3»). |
ino=5510 | L'objecte és identificat pel número d'«inode» 5510. |
scontext=system_u:system_r:syslogd_t:s0 | Aquest és el context de seguretat del procés que va executar l'operació. |
tcontext=system_u:object_r:device_t:s0 | Aquest és el context de seguretat de l'objecte destí. |
tclass=fifo_file | L'objecte de destinació és un fitxer «FIFO». |
allow syslogd_t device_t:fifo_file { read write }. Aquest procés es pot automatitzar, i és exactament el que ofereix l'ordre audit2allow (al paquet policycoreutils). Aquest enfocament només és útil si els diversos objectes ja estan etiquetats correctament segons el que s'ha de confinar. En qualsevol cas, haureu de revisar detingudament les normes generades i validar-les segons el vostre coneixement de l'aplicació. De fet, aquest enfocament tendeix a concedir més drets dels que realment es necessiten. La solució adequada és sovint crear nous tipus i concedir drets només sobre aquests. També pot passar que una operació denegada no sigui fatal per a l'aplicació, en aquest cas podria ser millor afegir una regla de «dontaudit» per evitar l'entrada al registre malgrat la denegació efectiva.
exemple.if,exemple.fc, i exemple.te) coincideixen amb les vostres expectatives per a les noves regles, canvieu-los el nom a myapp.extensió i executeu make NAME=devel per generar un mòdul al fitxer myapp.pp (el podeu carregar immediatament amb semodule -i myapp.pp). Si es defineixen diversos mòduls, make crearà tots els fitxers corresponents .pp.