Denne side bruger cookies
Dette forum bruger cookies. Hvis du er registreret, bruges de til at huske hvem du er logget ind som. Hvis ikke, gemmer vi dit sidste besøgstidspunkt. Besøgstidspunktet bruges bl.a. til at holde øje med, hvilke tråde du allerede har læst. Cookies er små tekstdokumenter, som bliver gemt i din browser og udgør ingen sikkerhedsrisiko. Tryk "Mere Information" nedenfor, for en liste over de cookies vi sætter. Du har mulighed for at fravælge cookies ved at klikke på knappen "Blokér Cookies" i bunden af denne boks.

En ikke-personhenførbar cookie vil blive gemt i din browser, uanset dit valg. Således undgår du at blive spurgt igen. Du kan til enhver tid ændre dit valg via linket i bunden af siden.

Tråd bedømmelse:
  • 1 Stemmer - 5 Gennemsnit
  • 1
  • 2
  • 3
  • 4
  • 5
SELinux 101
14-12-2014, 04:50
#1
SELinux 101
Under SELinux, køres systemet med MAC, Mandatory Access Control, hvor man uden SELinux kører Discresionary Acces Control.
Kort fortalt er DAC, de typiske Read, Write og Execute permissions, man kan sætte for root, brugere og "other".
Der er selvfølgelig untagelse, hvis man f.eks. kører med ACLs, som man også kan i Linux.
MAC tilbyder et miljø, der default har Deny på alt, og alt der skal kunne tilgå noget, skal have en Allow policy.

Der findes følgende fire forskellige måder at køre SELinux på:
Citer:Selinux 4 access control forms:
- Targeted Enforcement (TE)
- Strict - (TE bare mere strict)
- Role Based Access Control (RBAC)
- Multi-Level Access (MLS)
MCS er en Multi Category System og er en overbygning på MLS. Denne intro til SELinux dækker kun TE, selv om kommandoerne sådan set, er de samme.

SELinux er bygget op omkring Labels. Alt får en label, og denne fortæller, hvad der tillades.

Hvis man vil undersøge, hvilken label en fil har, kan man ikke bruge ls -l, som ellers sidder i fingrene hos de fleste:
Citer:root@selinux:~# ls -l
totalt 4
-rw-r--r--. 1 root root 11 dec 13 22:42 text.txt
root@selinux:~#

Man kan dog se, der er kommet et punktun efter "-rw-r--r--", altså "-rw-r--r--.", og dette viser, filerne på dette system, har fået labels.
Det er her, man ville se et +, hvis systemet kørte med Access Lists.
Vi er så heldige, at tegnet Z, ikke bruges i så forfærdelig mange kommandoer på linux, og derfor bliver dette brugt til at vise labels med i SELinux.
Citer:root@selinux:~# ls -Z
unconfined_u:object_r:user_home_t:SystemLow text.txt
root@selinux:~# ls -lZ
totalt 4
-rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:SystemLow 11 dec 13 22:42 text.txt
root@selinux:~#

Får du ikke dette output, kan du kontrollere at SELinux kører med:
root@selinux:~# check-selinux-installation
/etc/pam.d/login is not SELinux enabled
Citer:root@selinux:~# sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: default
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: denied
Max kernel policy version: 26
root@selinux:~#

Hvis du ikke har behov for al informationen, som ovenstående kommando giver, kan man nøjes med at bruge "getenforce":
Citer:root@selinux:~# getenforce
Enforcing
root@selinux:~#

Denne viser dog ikke, om SELinux vil køre, efter en reboot.

Alt har labels, når man har aktiveret SELinux. Både filer, sockets, processes, brugere osv.
Her er et eksempel på hvordan root ser ud lige nu:
Citer:root@selinux:~# id -Z
unconfined_u:unconfined_r:unconfined_t:SystemLow-SystemHigh
root@selinux:~# id
uid=0(root) gid=0(root) grupper=0(root) kontekst=unconfined_u:unconfined_r:unconfined_t:SystemLow-SystemHigh
root@selinux:~#

Her er den kørende Apache2 process:
Citer:root@selinux:~# ps -efZ |grep apache
system_u:system_r:httpd_t:s0 root 2184 1 0 21:54 ? 00:00:00 /usr/sbin/apache2 -k start
system_u:system_r:httpd_t:s0 www-data 2187 2184 0 21:54 ? 00:00:00 /usr/sbin/apache2 -k start
system_u:system_r:httpd_t:s0 www-data 2188 2184 0 21:54 ? 00:00:00 /usr/sbin/apache2 -k start
system_u:system_r:httpd_t:s0 www-data 2189 2184 0 21:54 ? 00:00:00 /usr/sbin/apache2 -k start
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 2720 2597 0 22:51 pts/0 00:00:00 grep apache
root@selinux:~#

Brugere i SELinux er dog ikke det samme som, den bruger man logger ind med. Flere linux brugere, kan være under samme SELinux bruger. Lidt som en gruppe af brugere, deler nogle rettigheder.
En Process kaldes i SELinux for et "subject", og filer, directories, FIFOs, sockets osv., er "objects". Så subjects arbejder på objects, når man benytter SELinux.
En label er i "context", når de er assosieret med en fil, og i et "domain", hvis en label er assosieret med en process.
Hvis vi ønsker at se, hvilke SELinux brugere og roller, der er configureret, kan vi gøre det med semanage:
Citer:root@selinux:~# semanage user -l

Labeling MLS/ MLS/
SELinux User Prefix MCS Level MCS Range SELinux Roles

root sysadm SystemLow SystemLow-SystemHigh staff_r sysadm_r system_r
staff_u staff SystemLow SystemLow-SystemHigh staff_r sysadm_r
sysadm_u sysadm SystemLow SystemLow-SystemHigh sysadm_r
system_u user SystemLow SystemLow-SystemHigh system_r
unconfined_u unconfined SystemLow SystemLow-SystemHigh system_r unconfined_r
user_u user SystemLow SystemLow user_r
root@selinux:~#

Hvis man ønsker at tildele en bruger, en bestemt rolle, kan det gøres således:
Citer:root@selinux:~# semanage login -a -s staff_u mian
root@selinux:~#

Som vi kan se fra ovensstående eksempl med apache2, er en label delt op i flere dele: user:role:type:level.
Hvis det ser lidt underligt ud, at apache2 både kører som root og www-data, er det fordi, Apache2 virker sådan.
Apache2 starter som root, så det kan læse certifikater osv., når den starter, den degraderer så sine egne rettigheder til www-data brugeren, og kører med den.
Apache2 har følgende label: system_u:system_r:httpd_t:s0.
System_u = user, system_r = role, httpd_t = type og s0 er adgangsniveauet.
Adgangsniveauet bruges ikke sønderligt i SELinux, når man kører Targeted Enforcement (TE), men er en form for adgangsniveau opdeling, f.eks. s0-s15 hvor S0 kunne svare til Public Information og S15 kunne være Top Secret.
Nogle ses som C0-c1023.

Her er et andet eksempel:
Citer:root@selinux:~# ls -lZ /etc/resolv.conf
-rw-r--r--. 1 root root system_u:object_r:net_conf_t:SystemLow 38 dec 13 22:47 /etc/resolv.conf
root@selinux:~#

Kører man Permissive eller Enforcing SELinux bør alt have en label, og det er ufarligt at skifte mellem disse to modes.
Man skal dog passe på med at gå direkte fra at have SELinux Disabled, til Enforced, for så er det ikke sikkert, alle labels er på plads og korrekte.
Der er flere måder at få sat labels på alt, på:

Citer:#fixfiles relabel // Gør dette på et kørende system
#touch /.autorelabel // Findes "/.autorelabel" filen, bliver der dannet labels ved reboot.
#fixfiles onboot // Denne schedulerer en relabel ved næste reboot. Effektivt det samme som at danne en /.autorelabel fil.

Hvis man vil ekskludere nogle filer fra at blive relabeled af fixfiles, kan disse angives i "/etc/selinux/fixfiles_exclude_dirs". Det er ikke sikkert, filen findes på forhånd.

Brugerfiler og bruger processes, vil ofte være labeled unconfinded_u, hvor systemfiler og system processes, ofte vil have system_u i stedet. Det kan også være user_u.
Hvis noget kører uden en targeted policy, vil det formegentlig køre unconfined_u.

De fleste distributioner har haft SELinux i mange år, og nogle kommer faktisk i dag, med en Permissive SELinux.
Det betyder også at når man installerer pakker, så får man, til lagt de fleste, færdiglavede policies med, og skal ikke tænke på at lave dem selv.
Lige det, hjælper ikke udviklere, som laver deres egne programmer, compiler et program fra source, eller bruger en tar ball.
Hvordan sætter vi så disse labels? Det er der flere svar på. Jeg vil starte med et typisk pitfall, før vi dykker ned i detaljerne.
SELinux labels flytter på samme måde som DAC permissions gør.

Når man opretter en ny fil, arver sin context fra det directory, den ligger i.
Flytter man en fil, vil filens context flytte med. Så man skal være varsom, hvis man flytter filer fra en context til en anden.
Hvis man kopierer en fil, og destinationsfilen allerede eksisterer, vil den nye fil, overtage den gamle fils label. Altså hvis man kopierer ovenpå den eksisterende.
Kopierer man en fil, og den ikke allerede findes, der hvor den kopieres hen, svarer det til en ny fil, og filen vil arve sin context, fra det directory, filen kommer til at ligge i, efter kopieringen.

Hvis man f.eks. selv har compilet nmap, som har brug for lidt flere rettigheder, end de andre filer man har i /usr/bin/, vil nmap arve sin context, eller få en label, ud fra, den context, /usr/bin mappen har.
Det kan man formegntlig ikke få nmap til at køre med, og det kan vi ændre på flere forskellige måder.
Vi kan bruge "chcon", som står for Change Context, eller vi kan bruge "semanage". Nedenstående to kommandoer gør det samme:

Citer:#chcon --type traceroute_exec_t /usr/bin/nmap // Change Context type traceroute_exec_t for /usr/bin/nmap
#semanage fcontext -a -t traceroute_exec_t /usr/bin/nmap // Add filecontext type traceroute_exec_t for /usr/bin/nmap

Bemærk at _t i traceroute_exec_t står for type, så derfor bruger vi -t for type, eller --type.

Får man ændret noget, man ikke ville have ændret, kan man bruge "restorecon" til at restore den originale context for den fil, man har ændret:
Citer:#restorecon /usr/bin/nmap

Man kan selvfølgelig også bruge chcon og restorecon rekursivt, hvis det er nødvendigt. Det kan være brugbart, hvis man f.eks. har fået rodet for meget i /var/www.
Så kan man rekursivt genskabe sin context med kommandoen:
Citer:#restorecon -R /var/www

Her er et eksempel på, hvordan en fil ændres fra type user_home_t til etc_t, og herefter tilbage:
Citer:root@selinux:~# ls -lZ
totalt 4
-rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:SystemLow 11 dec 13 22:42 text.txt
root@selinux:~# chcon --type etc_t ./text.txt
root@selinux:~# ls -lZ
totalt 4
-rw-r--r--. 1 root root unconfined_u:object_r:etc_t:SystemLow 11 dec 13 22:42 text.txt
root@selinux:~# restorecon ./text.txt
root@selinux:~# ls -lZ
totalt 4
-rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:SystemLow 11 dec 13 22:42 text.txt
root@selinux:~#

Hvis man har lavet en ny fil der hedder foo.html, kan man sætte dens context, ved at henvise til det directory, filen ligger i.
Den er meget tilsvarende de andre metoder:
Citer:#chcon --reference /var/www/html /var/www/html/foo.html

OBS: chcon er i deb pakken coreutils og semanage er i policycoreutils. Man kan også kaste et blik på man eller info page for genhomedircon og setfiles kommandoerne.

Hvis man ønsker at bruge sin home folder, til webindhold, som man ofte gør, hvis man bruger vhosts til hjemmesider, kan man sætte disse filer til typen httpd_sys_content_t.
Citer:#semanage fcontext -a -t httpd_sys_content_t "/home/bob/html(/.*)?" // Bemærk at i en shell, vil udsagn i gåseøjne, bliver fortolket.

Det kan også være man ønsker at have nogle CGIs tilgængelig, for at skabe noget dynamisk indhold:
Citer:#semanage fcontext -a -t httpd_sys_script_exec_t "/home/bob/html/cgi-bin(/.*)?"

En ting man støder på, hvis man f.eks. flytter sine html filer til sit home dir, er at webserveren vil blive nægtet adgang.
Dette skyldes af apache2 kører i en anden context end din home folder:
Citer:root@selinux:/var/www# ls -lZ
totalt 4
-rw-r--r--. 1 root root system_u:object_r:httpd_sys_content_t:SystemLow 177 dec 13 20:00 index.html
root@selinux:/var/www# ls -lZ /root
totalt 4
-rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:SystemLow 11 dec 13 22:42 text.txt
root@selinux:/var/www#

En home folder har en helt anden label. typen er user_home_t, hvor den i /var/www/ er httpd_sys_content_t.
For ikke at ødelægge det for meget for sig selv, kan man med fordel benytte sig af SELinux booleans.
Det er en form for shortcuts, som enten kan være slået til eller fra. Eller det var engang, og det lader vi som om, det stadig er.
For at give apache2 adgang til sit hjemmedrev, kan man sætte en boolean som hedder httpd_enable_homedirs.
Dette kan, som det meste andet, gøres på flere måder. Nedenstående kommandoer gør det samme:
Citer:#semanage boolean -m --on httpd_enable_homedirs
#setsebool httpd_enable_homedirs on // Sættes til off ved næste reboot.
#setsebool -P httpd_enable_homedirs on // Permanent sat til on

Som man kan se her under, fortæller de ikke noget, når det går godt.
Citer:root@selinux:~# setsebool -P httpd_enable_homedirs on
root@selinux:~# setsebool -P httpd_enable_homedirs off
root@selinux:~# echo $?
0
root@selinux:~#

Der er rigtig mange af disse booleans, og disse kan ses med semanage, eller getsebool kommandoerne. Hvis man f.eks. ønsker at tillade CGI, kan man tilføle en "grep" sammen med kommandoerne.
Her er et par eksempler med de to kommandoer. Man kan se, de har forskelligt output:
Citer:root@selinux:/var/www# getsebool -a |grep cgi
httpd_enable_cgi --> off
root@selinux:/var/www# semanage boolean -l |grep cgi
httpd_enable_cgi (off , off) httpd_enable_cgi
root@selinux:/var/www#

For at få en idé om, hvilke booleans der er, er det bare at køre en af ovenstående kommandoer, uden at smide det i gennem grep.

OBS: setsebool og getsebool er i pakken policycoreutils, lige som semanage.

En anden ting man sikkert vil støde på, er at apache2 kun må lytte på port 80 og 443. Det er godt hvis det er en prod server, alle kan tilgå fra Inetnettet.
Hvis det f.eks. lykkes en hacker at uploade netcat og er han nød til at sætte den til at lytte på en anden port end 80 eller 443, da apache bruger disse to.
Så vil det ikke være muligt for Apache2s address space, at lytte på andre porte. Men det kan være, man ønsker at køre software som webmin eller lign., som normalt lytter på tcp port 10000.
Så er man nød til at ændre http_port_t, så apache2 får lov til at lytte på den ønskede port.
Dette kan også gøres med semanage, med følgende kommando:
Citer:#semanage port -a -t http_port_t -p tcp 10000

Ønsker man at se, de porte der er registreret i SELinux, kan man gøre det med kommandoen semanage. Der er en hel del, da det svarer meget til /etc/hosts.
Her kan vi se, hvilke porte der er tilknyttet ftp:
Citer:root@selinux:~# semanage port -l |grep ftp
ftp_data_port_t tcp 20
ftp_port_t tcp 21, 990
ftp_port_t udp 990
tftp_port_t udp 69
root@selinux:~#

Hvad gør man så, når det ikke virker? Hvis man har installeret auditd pakken, vil der komme meddelelser i /var/log/audit/audit.log, og det vil jeg bestemt anbefale.
Ellers må man undersloge /var/log/messages for output.
Outputtet er lidt finurligt, og tidsstemplingen er i et forunderligt format.
For at få noget at se på, har jeg started exim op igen:
Citer:root@selinux:/usr/bin# service exim4 start
[ ok ] Starting MTA: exim4.
root@selinux:/usr/bin# tail /var/log/audit/audit.log
type=AVC msg=audit(1418516379.429:29): avc: denied { read write } for pid=3148 comm="hostname" path="socket:[6167]" dev=sockfs ino=6167 scontext=system_u:system_r:hostname_t:s0-s0:c0.c1023 tcontext=system_u:system_r:dhcpc_t:s0-s0:c0.c1023 tclass=udp_socket
type=SYSCALL msg=audit(1418516379.429:29): arch=c000003e syscall=59 success=yes exit=0 a0=262adc8 a1=262aea8 a2=260cc08 a3=0 items=0 ppid=3146 pid=3148 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="hostname" exe="/bin/hostname" subj=system_u:system_r:hostname_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1418516952.974:30): avc: denied { search } for pid=3417 comm="exim4" name="crypto" dev=proc ino=11291 scontext=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysctl_crypto_t:s0 tclass=dir
type=SYSCALL msg=audit(1418516952.974:30): arch=c000003e syscall=2 success=no exit=-13 a0=7f5453269b10 a1=0 a2=1b6 a3=0 items=0 ppid=3416 pid=3417 auid=0 uid=101 gid=104 euid=101 suid=101 fsuid=101 egid=104 sgid=104 fsgid=104 tty=pts0 ses=1 comm="exim4" exe="/usr/sbin/exim4" subj=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1418516953.118:31): avc: denied { search } for pid=3422 comm="exim4" name="crypto" dev=proc ino=11291 scontext=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysctl_crypto_t:s0 tclass=dir
type=SYSCALL msg=audit(1418516953.118:31): arch=c000003e syscall=2 success=no exit=-13 a0=7fbf62c29b10 a1=0 a2=1b6 a3=0 items=0 ppid=3421 pid=3422 auid=0 uid=101 gid=104 euid=101 suid=101 fsuid=101 egid=104 sgid=104 fsgid=104 tty=pts0 ses=1 comm="exim4" exe="/usr/sbin/exim4" subj=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1418516953.282:32): avc: denied { search } for pid=3425 comm="exim4" name="crypto" dev=proc ino=11291 scontext=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysctl_crypto_t:s0 tclass=dir
type=SYSCALL msg=audit(1418516953.282:32): arch=c000003e syscall=2 success=no exit=-13 a0=7f0710c0ab10 a1=0 a2=1b6 a3=0 items=0 ppid=3424 pid=3425 auid=0 uid=101 gid=104 euid=101 suid=101 fsuid=101 egid=104 sgid=104 fsgid=104 tty=pts0 ses=1 comm="exim4" exe="/usr/sbin/exim4" subj=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1418516953.418:33): avc: denied { search } for pid=3433 comm="exim4" name="crypto" dev=proc ino=11291 scontext=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysctl_crypto_t:s0 tclass=dir
type=SYSCALL msg=audit(1418516953.418:33): arch=c000003e syscall=2 success=no exit=-13 a0=7ff878797b10 a1=0 a2=1b6 a3=0 items=0 ppid=3431 pid=3433 auid=0 uid=101 gid=104 euid=101 suid=101 fsuid=101 egid=104 sgid=104 fsgid=104 tty=(none) ses=1 comm="exim4" exe="/usr/sbin/exim4" subj=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 key=(null)
root@selinux:/usr/bin#

For at skille, hvad der er gået godt, og hvad der ikke er, kan man med fordel bruge grep. En ting man kan søge på, er "denied", en anden ting er AVC.
Når der i SELinux opstår en access violation, altså når en policy ikke er blevet overholdt, kommer der en AVC (Access Vector Cache) besked.
Denne kan man greppe efter:
Citer:root@selinux:/usr/bin# tail /var/log/audit/audit.log |grep AVC
type=AVC msg=audit(1418516379.429:29): avc: denied { read write } for pid=3148 comm="hostname" path="socket:[6167]" dev=sockfs ino=6167 scontext=system_u:system_r:hostname_t:s0-s0:c0.c1023 tcontext=system_u:system_r:dhcpc_t:s0-s0:c0.c1023 tclass=udp_socket
type=AVC msg=audit(1418516952.974:30): avc: denied { search } for pid=3417 comm="exim4" name="crypto" dev=proc ino=11291 scontext=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysctl_crypto_t:s0 tclass=dir
type=AVC msg=audit(1418516953.118:31): avc: denied { search } for pid=3422 comm="exim4" name="crypto" dev=proc ino=11291 scontext=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysctl_crypto_t:s0 tclass=dir
type=AVC msg=audit(1418516953.282:32): avc: denied { search } for pid=3425 comm="exim4" name="crypto" dev=proc ino=11291 scontext=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysctl_crypto_t:s0 tclass=dir
type=AVC msg=audit(1418516953.418:33): avc: denied { search } for pid=3433 comm="exim4" name="crypto" dev=proc ino=11291 scontext=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysctl_crypto_t:s0 tclass=dir
root@selinux:/usr/bin#

En bedre måde at søge efter disse fejl på, er at bruge en af de gode linux audit værktøjer, der kommer prepacked fra distributøren.
Et af dem er ausearch, som er bygget til at søge i daemon logs.

OBS: ausearch er i pakken auditd, som også giver /var/log/audit/audit.log filen.

Her kan vi se, hvordan de samme beskeder fra exim4 processen er opstillet gennem ausearch. Dette er en søgning på AVC beskeder som ikke er gået godt:
Citer:root@selinux:/usr/bin# ausearch -i -m AVC,USER_AVC -sv no
----
type=SYSCALL msg=audit(13-12-2014 21:55:00.491:10) : arch=x86_64 syscall=bind success=no exit=-13(Adgang nægtet) a0=7 a1=7feb2dbfd260 a2=6e a3=7feb2b47714c items=0 ppid=1 pid=2446 auid=unset uid=postgres gid=postgres euid=postgres suid=postgres fsuid=postgres egid=postgres sgid=postgres fsgid=postgres tty=(none) ses=4294967295 comm=postgres exe=/usr/lib/postgresql/9.1/bin/postgres subj=system_u:system_r:postgresql_t:s0 key=(null)
type=AVC msg=audit(13-12-2014 21:55:00.491:10) : avc: denied { create } for pid=2446 comm=postgres name=.s.PGSQL.5432 scontext=system_u:system_r:postgresql_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file
----
type=SYSCALL msg=audit(14-12-2014 01:29:13.118:31) : arch=x86_64 syscall=open success=no exit=-13(Adgang nægtet) a0=7fbf62c29b10 a1=0 a2=1b6 a3=0 items=0 ppid=3421 pid=3422 auid=root uid=Debian-exim gid=Debian-exim euid=Debian-exim suid=Debian-exim fsuid=Debian-exim egid=Debian-exim sgid=Debian-exim fsgid=Debian-exim tty=pts0 ses=1 comm=exim4 exe=/usr/sbin/exim4 subj=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(14-12-2014 01:29:13.118:31) : avc: denied { search } for pid=3422 comm=exim4 name=crypto dev=proc ino=11291 scontext=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysctl_crypto_t:s0 tclass=dir
----
type=SYSCALL msg=audit(14-12-2014 01:29:12.974:30) : arch=x86_64 syscall=open success=no exit=-13(Adgang nægtet) a0=7f5453269b10 a1=0 a2=1b6 a3=0 items=0 ppid=3416 pid=3417 auid=root uid=Debian-exim gid=Debian-exim euid=Debian-exim suid=Debian-exim fsuid=Debian-exim egid=Debian-exim sgid=Debian-exim fsgid=Debian-exim tty=pts0 ses=1 comm=exim4 exe=/usr/sbin/exim4 subj=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(14-12-2014 01:29:12.974:30) : avc: denied { search } for pid=3417 comm=exim4 name=crypto dev=proc ino=11291 scontext=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysctl_crypto_t:s0 tclass=dir
----
type=SYSCALL msg=audit(14-12-2014 01:29:13.282:32) : arch=x86_64 syscall=open success=no exit=-13(Adgang nægtet) a0=7f0710c0ab10 a1=0 a2=1b6 a3=0 items=0 ppid=3424 pid=3425 auid=root uid=Debian-exim gid=Debian-exim euid=Debian-exim suid=Debian-exim fsuid=Debian-exim egid=Debian-exim sgid=Debian-exim fsgid=Debian-exim tty=pts0 ses=1 comm=exim4 exe=/usr/sbin/exim4 subj=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(14-12-2014 01:29:13.282:32) : avc: denied { search } for pid=3425 comm=exim4 name=crypto dev=proc ino=11291 scontext=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysctl_crypto_t:s0 tclass=dir
----
type=SYSCALL msg=audit(14-12-2014 01:29:13.418:33) : arch=x86_64 syscall=open success=no exit=-13(Adgang nægtet) a0=7ff878797b10 a1=0 a2=1b6 a3=0 items=0 ppid=3431 pid=3433 auid=root uid=Debian-exim gid=Debian-exim euid=Debian-exim suid=Debian-exim fsuid=Debian-exim egid=Debian-exim sgid=Debian-exim fsgid=Debian-exim tty=(none) ses=1 comm=exim4 exe=/usr/sbin/exim4 subj=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(14-12-2014 01:29:13.418:33) : avc: denied { search } for pid=3433 comm=exim4 name=crypto dev=proc ino=11291 scontext=unconfined_u:system_r:exim_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysctl_crypto_t:s0 tclass=dir
root@selinux:/usr/bin#

Bemærk at tidsstemplingen nu er til at læse.
Nogle gange, kan man være nød til at rette eksisterende policies, men det anbefales at rapportere disse fejl til distributøren af pakken, så det kan blive rettet.
Måske skal man lave en policy til et program, man selv har lavet, og dette kan gøres med audit2allow, som kommer i policycoreutils pakken.
Man kan skrive sin policy i hånden, eller man kan vælge at tage de deny AVCs fra audit.log, og lade audit2allow lave en allow policy for dig.
Reelt set, kan man pipe indholdet fra /var/log/audit/audit.log direkte ind i audit2allow, men der er en god chance for, den policy man får ud i den anden ende, tillader lidt for meget.
Citer:#audit2allow < /var/log/audit/audit.log

Ovenstående må anses som at være aller sidste udvej.

Man kan f.eks. udstede følgende kommando, som laver en Type Enforcementrule, ud fra deny AVCs fra de sidste 5 minutter, der tillader denne handling:
Citer:#ausearch -i -m AVC -sv no -ts recent | audit2allow

Får man ikke hvad man forventer, skal man være opmærksom på, meddelelserne kan være mere end 5 minutter gamle. Se man eller info page for ausearch. De kan rigtig mange ting.
Her er et par søgninger:
Citer:root@selinux:~# ausearch -i -m AVC -sv no | grep exim4 | audit2allow


#============= exim_t ==============
allow exim_t sysctl_crypto_t:dir search;
root@selinux:~# ausearch -i -m AVC -sv no -se exim_t | audit2allow


#============= exim_t ==============
allow exim_t sysctl_crypto_t:dir search;
root@selinux:~#

Lad os prøve at lave en ny policy. Vær dog opmærksom på, du kan risikere at overskrive en eksisterende policy, hvis du vælger samme navn.
Citer:root@selinux:~# ausearch -i -m AVC -sv no -se exim_t | audit2allow -m ny-exim > ny-exim.te
root@selinux:~# cat ny-exim.te

module ny-exim 1.0;

require {
type sysctl_crypto_t;
type exim_t;
class dir search;
}

#============= exim_t ==============
allow exim_t sysctl_crypto_t:dir search;
root@selinux:~#

Så har vi dannet en ny policy. Denne skal så "kompileres, linkes og loades", før den virker.
Bemærk versionsnummeret i den. Denne er dannet med version 1.0, og det anbefales at ændre denne, hver gang, denne policy ændres.
Det gør det i hvert fald nemmere at holde hånd i hanke med, hvilken policy, der er den nyeste og formegntlig, den der er loaded ind i linux kernen.

Det næste trin er at danne en .mod fil og dette gøres med følgende kommando:
Citer:root@selinux:~# checkmodule -M -m -o ny-exim.mod ny-exim.te
checkmodule: loading policy configuration from ny-exim.te
checkmodule: policy configuration loaded
checkmodule: writing binary representation (version 14) to ny-exim.mod
root@selinux:~# ls -lZ ny*
-rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:SystemLow 923 dec 14 02:08 ny-exim.mod
-rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:SystemLow 169 dec 14 02:03 ny-exim.te
root@selinux:~#

Så skal vi have lavet en policy module package fra det binære policy modul. Der efter loades vores nye package ind i linux kernen, hvor SELinux lever:
Citer:root@selinux:~# semodule_package -o ny-exim.pp -m ny-exim.mod
root@selinux:~# ls -lZ ny*
-rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:SystemLow 923 dec 14 02:08 ny-exim.mod
-rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:SystemLow 939 dec 14 02:13 ny-exim.pp
-rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:SystemLow 169 dec 14 02:03 ny-exim.te
root@selinux:~# semodule --install ny-exim.pp
root@selinux:~#

Det tager lidt tid at loade modulet, men det er normalt. Jeg har ladet mig fortælle, der kan gå lidt tid, før modulet rent faktisk bliver aktivt.
Lad os prøve at tømme audit.log og genstarte exim4. Hvis vi ikke får nogen AVCer, lader det til, vores nylavede policy virker:
Citer:root@selinux:~# service exim4 stop
[ ok ] Stopping MTA: exim4_listener.
root@selinux:~# rm /var/log/audit/audit.log
root@selinux:~# touch /var/log/audit/audit.log // Måske skal man efter denne kommando, lave en restorecon /var/log/audit/audit.log
root@selinux:~# service exim4 start
[ ok ] Starting MTA: exim4.
root@selinux:~# cat /var/log/audit/audit.log
root@selinux:~#

Virker den policy man har lavet, ikke efter hensigten, kan den unloades med samme kommando, som den blev loaded med, bare med --remove i stedet for --install.
Citer:root@selinux:~# semodule --remove ny-exim.pp
root@selinux:~#

Når man tester sin SELinux installation, og arbejdet med nogle problemer, har man den mulighed, at sætte hele sytemet i Permissive mode.
Så kan man debugge, ved at se i /var/log/audit.log, men slippe for, at systemet ikke virker.
Hvis man vælger at gøre dette, skal man selvfølgelig være opmærksom på, man har fravalgt SELinux beskyttelsen for hele systemet, og det kan potentielt, efterlade systemet åbent, mens du arbejder.
En anden og måske bedre måde, er at sætte Permissive mode på den enkelte process, i stedet for hele systemet.
Så har resten af systemet sikkerheden fra SELinux, mens man frit kan arbejde med den process, der giver problemer.
Citer:#semanage permissive -a exim_t // Tillader at exim4 kører permissive, selv om resten af systemet kører enforced.
#semanage permissive -d exim_t // Fjerner tilladelsen, så exim4 ikke længere må bryde sin policy.
#semanage permissive -l // Lister de tilladelser der er givet, til at køre permissive.

Jeg skal dog sige, jeg ikke kan få ovenstående til at virke lige nu.

For at få adgang til filer og andet, skal man selvfølgelig også have adgang via DACs RWX.
Der er rigtig meget læsestof i man og info pages.
SELinux er en god og nem måde at gøre en maskine lidt mere sikker på, og det brude faktisk ikke være opt-in, men opt-out, efter min mening.
Jeg vil dog ikke anbefale, at installere det på din legeplads. Og vær opmærksom på, det reelt er en chance for, du får lukket dig selv ude.
SELinux til Debian er efterhånden rimelig godt med. Der kan dog stadig være nogle udfordringer med nogle display managere, som skal have finpudset deres policies.
En anden ting man skal være opmærksom på er, at kommandoer udføres langsomt. Der er en del overhead, når man gør noget, hvor adgangen skal kontrolleres.
Det påvirker ikke daemons det store. De bliver et ekstra sekund på at starte, men når de først kører, burde man ikke mærke noget til det.

https://github.com/TresysTechnology/refpolicy/wiki
https://wiki.debian.org/SELinux/Setup?hi...etup%29%29
---
Writing a shellcode decoder stub in assembly is like talking gibberish in such a way that it is still perfectly intelligible. - iTick
Besøg denne brugers hjemmeside Find alle beskeder fra denne bruger
Citer denne besked i et svar
« Ældre | Nyere »




User(s) browsing this thread: 1 Gæst(er)