Sigurniji operativni sistemi (8. deo) — sigurnosni dodaci GNU/Linuks sistemu

Autor: Petar Simović

Vaš svakodnevni linuks verovatno je već dovoljno siguran sam po sebi ukoliko blagovremeno ažurirate sistem i imate dobre različite šifre za različite naloge, ali svakako da postoje programi koji ga mogu učiniti manje bezbednim. Programi koji se naknadno instaliraju, preuzimaju sa neproverenih sajtova na internetu, loše konfigurisani programi, sudo privilegije dodeljene programima i korisnicima bez potrebe, otvoreni portovi, neažurirani sistem i sistemski softveri, kao i sve veći broj virusa i ranjivosti koji se pronalaze i objavljuju za linuks operativne sisteme.

Međutim, sigurnost linuks sistema se može značajno unaprediti kroz par dodataka za sam kernel takozvanim LSM modulima (eng. LSM – Linux Security Modules), i sa određenim sistemskim softverom za izolaciju programa jednih od drugih.

U prethodnim brojevima već smo pominjali neke od njih, pa smo tako u prošlom delu objasnili ukratko Grsek (eng. Grsec) i njegove module PAX i RBAC, a ovde ćemo da detaljnije opišemo još neke module za veću zaštitu samog jezgra linuks sistema, poređenje zaštitnih mogućnosti, kao i kako da ih vi upotrebite na vašem linuksu.

Zavisno od distribucije koju koristite imaćete drugačiji nivo zaštite linuks jezgra, tj. drugačije module za zaštitu jezgra omogućene na sistemu. Tako na primer standardni Ubuntu sistem dolazi sa Aparmorom (eng. AppArmor) omogućenim, dok pomenuti Heds (eng. HEADS) u prošlom delu dolazi sa Grsek modulom. Sigurnosni moduli imaju ulogu osiguravanja da do neovlašćenog pristupa ne dođe, a ako i dođe zbog ranjivosti samog sistema i programa da šteta po ostali deo sistema bude najmanja moguća tj. da se šteta ili upad maksimalno ograniči. Sigurnosni moduli bi trebalo da osiguraju kernel i izoluju aplikacije jedne od drugih, proveravaju integritet sistema tj. jezgra, omoguće kontrolu nad pristupom fajlovima i programima.

Pravila upravljanja pristupa fajlovima u operativnim sistemima. Obično linuks distribucije dolaze sa sistemom upravljanja fajlovima zasnovanim na privilegijama koje imaju korisnici ili grupe kojima korisnici pripadaju. Tako na primer određeni korisnik ili grupa može biti vlasnik nekog fajla što vlasniku/cima daje pravo da taj fajl menjaju. Ovakav sistem se naziva DAC (eng. Discretionary access control). Ovaj sistem se primenjuje na linuksu od šezdesetih godina i ne pruža zaštitu od malicioznog softvera ili bagova.

Za razliku od DAC-a postoji i MAC (eng. Mandatory access control) koji pored vlasnika imaju i polisu za fajlove ili direktorijume tj. nivo ovlašćenja čak i nad fajlovima koje sami kreiraju. Najvidljivija razlika je upravo u kontroli nad fajlovima, gde kod DAC-a korisnici sami mogu da odlučuju o sigurnosnim atributima fajlova tj. njihovoj dostupnosti, dok su kod MAC-a sva sigurnosna ograničenja implementirana kroz pravila i polise koje određuje samo administrator. Druga značajna razlika je u tome što kod DAC-a korisnik sa većim privilegijama može da korisniku sa manjim dodeli više privilegije, dok kod MAC-a to nije moguće.

ACL (eng. Access Controll list) je najjednostavniji sistem koji procesima ili korisnicima dodeljuje određena prava nad fajlovima ako što su pravo čitanja, pisanja ili izvršavanja. Više korisnika mogu imati različita prava nad istim fajlom.

Sledeći sistem je RBAC (eng. Role Based Access Control) koji je sličan kao ACL ali definiše i operacije koje su dozvoljene ACL-om. Primera radi ACL može definisati da određeni korisnici mogu da edituju fajl, dok RBAC ima opciju da definiše šta to konkretno znači u tom slučaju, tj. šta se sme izmeniti. Ovaj sistem je proširenje ACL-a primenjeno u velikim korporacijama gde postoji potreba da se preciznije reguliše ko šta može izmeniti i kako na deljenim fajlovima na osnovu uloga (eng. roles) koje imaju korisnici.

ABAC (eng. Attribute-based access control) je nešto komplikovaniji sistem koji se smatra novom generacijom sistema za kontrolu pristupa. Dok RBAC primenjuje uloge koje neki korisnik ima, ABAC primenjuje sistem definisanja preduslova na osnovu polisa i uloga korisnika preko AKO-ONDA (eng. IF-THEN) bulovih funkcija. Na primer: Ako je korisnik u odeđenoj grupi koja ima pravo pristupa, i ako je član odeđenog odeljenja u kompaniji, može pristupiti sa odeđenim predefinisanim privilegijama fajlu samo tokom radnog vremena.

Više možete pročitati na Vikipediji ili sa sledećeg linka.

Grsekjuriti (eng. Grsecurity) – ili Grsek služi generalnoj nameni, štiti sistem koji se povezuje sa nesigurnim sistemima preko mreže tj. interneta. Najčešći primer je za dodatnu zaštitu veb servera i primenjuje MAC sistem pristupa fajlovima.

U sebi ima PAX modul za razdvajanje memorije na onu sa podacima koja ne može da se izvršava i onu sa programima za izvršavanje čime sprečava prekoračenje bafera (eng. buffer overflow). PAX sadrži i nasumičan raspored adresnog prostora (eng. address space layout randomization) kako maliciozni programi ne bi mogli da predvide na kojoj adresi će se važni programi naći u RAM memoriji. U okviru Paksa je razvijen i Steklik (eng. StackLeak) dodatak koji nastoji zaštititi memoriju koju koristi linuks jezgro od napada na stek koji se mogu desiti zbog načina funkcionisanja rezervisanja i oslobađanja sistemske memorije.

Drugi sastvani deo Grseka je RBAC (eng. Role Based Access Control) koji je zadužen za kontrolu i dodeljivanje privilegija korisnicima i procesima. Koristi se princip najmanje privilegije (eng. Principle of least privilege) koji korisnicima i procesima daje minimalne neophodne privilegije za rad kroz linuks listu za kontrolu pristupa ACL (eng. Access-control list).

Grsek je dodatak (eng. patch) za linuks kernel koji kroz pomenute svoje delove pokušava ograničiti i umanjiti štetu koju napadač ili zlonamerni program mogu učiniti ukoliko dođu na sistem preko nekog korisnika ili programa.

SELinuks (eng. SELinux, Security Enchanced Linux) je takođe sigurnosni modul da linuks kernel koji implementira MAC. Razvijen od strane NSA (eng. Nacional Security Agency, USA) i objavljen krajem 2000. godine pod GPL licencom. SElinuks se podrazumevano koristi u Android operativnom sistemu od verzije 4.3, dok je na Fedori omogućen podraumevano, na Debijanu i Ubuntu dolazi uz kernel ali onemogućen podrazumevano pa ga Selinuks po želji omogućiti. Iako je SELinuks MAC sistem, DAC polise se i dalje poštuju tj. potrebno je budu zadovoljeni uslovi oba sistema kako bi se pristupilo nekom fajlu. SELinuks beležava programe, procese, fajlove, portove, … labelama, a onda se kroz pravila kontroliše ko ima pristup kojim labelama koje na kraju primenjuje kernel na ceo sistem.

Da li je SELinuks instaliran možete proveriti komandom kao i status polise:

# getenforce

Moguće ga je i instalirati na linuksu komandom (za debijan, APT):

apt install selinux-utils

Aparmor (eng. AppArmor) je takođe sigurnosni modul ta linuks kernel koji implementira MAC kao dodatak DAC-u koji već na linuksu postoji. Aparmor i SELinuks imaju isti cilj ali drugačije funkcionišu pa tako Aparmor predstavlja alternativu SELinuksu. Dok SELinuks koristi labele za kontrolu prava pristupa, Aparmor koristi pune putanje (putanje od korenskog direktorijuma /). Aparmor može biti omogućen u dva režima rada, režim za logovanje svih akcija bez prevencije tzv. režim za žalbe sistemu (eng. complaining mode) i režim za prevencije. Takođe logovi mogu biti veoma korisni ne samo za administratore kao uvid u dešavanja, već i za sam Aparmor kako bi kroz logove u fazi testiranja mogao da „nauči” šta treba da blokira i na osnovu toga napravi profile koje će koristiti u modu za prevencije pomoću aa-logprof komande sa kojom Aparmor može iz logova da unapredi svoje profile funkcionisanja sa odobrenjem administratora. Više na sledeća dva linka: link 1 i link 2. Aparmor je objavljen pod GPL licencom.

Svojstva Apramora su:

• može se primeniti na sistem bez restartovanja,
• ne zavisi od fajl sistema kao SELinuks koji zahteva fajl sistem koji ima mogućnost labelovanja,
• selektivno se može primeniti na pojedine aplikacije ili servise,

Status Aparmora se može videti komandom:

sudo apparmor_status

ili

aa-status

Smek (eng. SMACK – Simplified Mandatory Access Control Kernel) ja kao i SELinuks i Aparmor MAC sigurnosni dodatak za jezgro sa idejom na jednostavnosti i lakoći upotrebe dizajniran za ugrađene (eng. embedded systems). Imao je primenu u Migo (eng. MeeGo) i Tizen mobilnim sistemima, dok je Linuks fondacija ovaj sistem uvela kao obavezan za linuks aplikacije za automobile. Smek poput SELinuksa zahteva fajl sistem sa podrškom za labele ili atribute, ali je manje poznat i veoma retko se koristi na desktop i serverskim linuks sistemima. Smek je objavljen pod GPL2 licencom.

Tomojo (eng. TOMOYO) je još jedan dodatak zasnovan na MAC polisama sa mogućnošću analiziranja sistema i slično Aparmoru primenjuje osiguravanje procesa na osnovu apsolutnih putanji od korenskog direktorijuma. Tomojo je sličan Aparmoru i po mogućnosti nadzora sistema tj. režim učenja u kome se aplikacijama dozvoljava da se izvršavaju kako hoće kako bi se iz tog ponašanja izvukao šablon ponašanja svake pojedinačne aplikacije. Kada se naprave šabloni onda se može omogućiti režim primenjivanja naučenih polisa. Postoji mogućnost da se i pravi fajervol za svaku pojedinačno aplikaciju kao i pravljenja mamca sistema za rano otkrivanje mogućih napada (eng. honeypot), a Tomojo pokušava da spreči napade koji se mogu realizovati preko prekoračenja bafera. Tomojo je dostupan za instalaciju na Debijan, Centos i Opensus (eng. OpenSUSE) sistema kroz program tomoyo-tools.

Zanimljiva ilustracija kako ovaj sistem funkcioniše preuzeta sa njihovog sajta objašnjava režim rada sistema i aplikacija koje se izvršavanju bez Tomojo linuksa, onda sa njim u režimu učenja i na kraju u režimu primene naučenih polisa.

Loudpin (eng. LoadPin) je poseban LSM specifično namenjen za verifikaciju da su sve učitane komponente jezgra (moduli, drajevri, firmveri,…) sa istog fajl sistema, sa pretpostavkom da je sa uređaja na komje taj fajl sistema moguće samo čitati, a ne i pisati (eng. read only file sytem). Ova sigurnosna preocedura uvedena je kako bi se za ugrađene sisteme (eng. embedded systems) olakšalo osiguravanje kernela koji može biti smešnen na memoriju sa koje je moguće samo čitati. Loudpin je sastavni deo linuks jezgra od 4.7 verzije i podrazumevano omogućen, može se onemogućiti, a instalira se jedino pri kompajliranju kernela. Više na sledećim linkovima: link 1, link 2 i link 3.

Jama (eng. Yama) je LSM koji služi da ograniči upotrebu pi-trejs (eng. ptrace) sistemskog poziva i sastavni deo je linuksa od verzije 3.4 jezgra. Pi-trejs se može koristiti od strane programera da debaguju tj. ispitaju kako njihov program zapravo radi i ima li bagova, da li postoji curenje memorije, ali se može i zloupotrebiti jer omogućava jednom procesu da kontroliše i ispita drugi i tako omogućava recimo izvlačenje memorijskog sadržaja kontrolisanog procesa. Jama nije klasičan „punokrvni” LSM po gore navedenim vrstama jer obuhvata samo ograničavanje odeđenog sistemskog poziva na DAC sistemima tj. samo je dodatni sigurnostni mehanizam za pi-trejs sistemske pozive. Da li je Jama omogućena kod vas na sistemu možete proveriti komandom:

sysctl kernel.yama.ptrace_scope

dok je značenje vrednosti sledeće:

1. kernel.yama.ptrace_scope = 0 – normalno funkcionisanje pi-trejsa, svi procesi se mogu debagovati dok imaju isti SUID,
2. kernel.yama.ptrace_scope = 1 – samo roditelj procesa može biti debagovan,
3. kernel.yama.ptrace_scope = 2 – samo admin može koristiti pi-trejs jer zahteva CAP_SYS_PTRACE funcionalnost,
4. kernel.yama.ptrace_scope = 3 – ni jedan proces se nemože debagovati pi-trejsom, faktički pi-trejs je onemogućen i potrebno je restartovati računar da bi se primenio efekat.

Jama se koristi u Hrom ili Hromijum internet pregledaču i njen status možete proveriti odlaskom na link chrome://sandbox/. Više na sledeća dva linka: link 1 i link 2.

Sejf-set-aj-di (eng. SafeSetID) je dodatni modul za jezgro koji se tiče osiguravanja prelaska programa između korisnika različitih privilegija na sistemu bez eskalacije na korisnike većih privilegija. Funkcija koja kreira novi proces na sistemu od postojećeg za drugog korisnika ili prepušta postojeći proces drugom korisniku različitih, obično nižih privilegija, se može zloupotrebiti da podesi ID procesa na veći tj. na vrednost 0 što je korenski proces (eng. root process). Sejf-Set-AjDi sprečava ovaj scenario i nastoji da više izoluje procese jedne od drugih i sastavni deo je linuks jezgra od 5.1 verzije. Više na sledećem linku.

Lokdaun (eng Lockdown) je najnoviji LSM koji bi trebalo da omogući bolju zaštitu samog jezgra od korisničkih programa i pristup koji bi napadač mogao da ima ukoliko se kompromituje i rut korisnik. Lokdaun ima i još jednu značajnu primenu, a to je da omogući da verifikaciju kernala na početku startovanja računara koje pregleda Juefi (eng. UEFI Secure Boot). Trenutna situacija je takva da rut nalog može praviti izmene kernela, što u principu narušava integritet kernela i Juefi sigurnosne provere. Lokdaunom će se rut nalogu ograničiti pristup, i to kroz jedan od dva režima:

1. Režim integriteta – zabranjuje rut nalogu pristup interfejsima: /dev/{mem,kmem,port}, /dev/efi_test, i drugim načinima na koji rut nalog može komunicirati sa kernelom.
2. Režim poverljivosti – je režim integrita plus još: /proc/kcore, kprobes, korišćenje bpf-a da čita sadržaj RAM memorije.

Postojanje režima poverljivosti opravdava se činjenicom da se u memoriji računara koja pripada jezgru mogu naći poverljive informacije poput enkripcionih ključeva koji potencijalno mogu biti pročitane odstrane rut korisnika, pa je ovaj vid zaštite potreban prvenstveno za biznis korisnike koji imaju potrebu da osiguraju servere ili svoje računare od potencijalnog curenja poverljivih informacija u slučaju kompromitovanja rut naloga. Lokdaun je uveden u sastavni deo od 5.4 verzije linuks jezgra ali je podrazumevano isključen. Više informacija na sledećim linkovima: link 1, link 2, link 3 i link 4.

Iako je jasno da ima više sigurnosnih rešenja za naše linuks jezgro, može se postaviti pitanje koje rešenje je najbolje. Na to je teško odgovoriti jer su neka rešenja prikladnija serverima, neka desktop korisnicima, dok su jedna jednostavna druga komplikovanija ali sa više mogućnosti da se dobro konfigurišu (ili pogrešno) ako im se posveti više vremena. Druga ideja može biti koristiti više linuks sigurnosnih modula što je opet negde moguće a negde besmisleno jer ima više veoma sličnih rešenja koja rade istu stvar. Na primer, sasvim je moguće koristiti grsek i aparmor, dok je besmisleno kombinovati tomojo i aparmor. Razlog je jednostavan, grsek ima sigurnosne mehanizme specifično za srečavanje eksploita dok aparmor ograničava pristupe, a aparmor i tomojo rade skoro istu stvar i to na slične načine i ne dopunjuju se ni u čemu, mada i kod grseka i aparmora ima delova istih mehanizama ipak ima više smisla za kombinaciju. Međutim kombinacija sigurnosnih modula je izuzetno retka i teška pogotovo za obične korisnike desktopa, ne samo zato što bi verovatno zahtevala da se takav specifičan kernel namenski kompajlira, već i zato što bi se sigurnosni moduli „otimali” oko sistemskih resursa od kojih zavise kako bi normalno funkcionisali, pogotovo oni koji rade na sličnim principima.

Bacili smo pogled na neke od sigurnosnih modula za linuks jezgro i upoznali čitaoce sa načinima zaštita. U sledećem delu bavićemo se manje poznatim projektima koji mogu doprineti većoj bezbednosti svakodnevnog korišćenja linuksa ili znatno unaprediti kritične operacije.