You are here: TUTWiki>Tietoturva/Tutkielmat>TyoLuettelo?>2006-22

Raine Kervinen

UNIX-pääsynvalvonnan käytäntöjä

Johdanto

Aiheena on pohtia jonkin UNIX-pohjaisen järjestelmän ryhmäoikeuksien käyttöperiaatteita tietoturvan kannalta. Kokeilujärjestelmäksi käy myös Linux, eli tässä tapauksessa testiin otetaan Fedora Core 6, joka on asennettu ext3 tiedostojärjestelmään.

Työssä käsitellään tiedosto- ja käyttäjäoikeuksien myöntämisperiaatteita tietoturvallisuuden näkökulmasta, sekä tarkastellaan myös ryhmäoikeuksia, kuten vaikkapa erilaisten ryhmien jäsenyys tietoturvallisuuden kannalta. Työssä pyritään myös tarkastelemaan esimerkkitilanteiden avulla, miten ryhmiä voidaan käyttää pääsynvalvonnan tavoitteiden saavuttamiseksi. Lisäksi pyritään täydentämään kurssimateriaalista löytyviä tietoja SELinuxin osalta.

Tiedosto-oikeuksien yleiset asetusperusteet tietoturvallisuuden näkökulmasta

UNIX-järjestelmissä, kuten myös Linux-järjestelmissä, käytetään tiedosto- ja hakemisto-oikeuksia pääsynvalvonnan seurantaan. Yleisesti jokaisella hakemistolla ja tiedostolla on siis määriteltynä seuraavat oikeudet: luku-, kirjoitus- ja suoritusoikeus. [1] Jokaisella hakemistolla ja tiedostolla on myös omistaja (owner, yleisesti jokin käyttöjärjestelmän käyttäjätunnus, esim. kervinen), ryhmä (users, admin, root, kervinen) sekä muut (others), eli sellaiset käyttäjätunnukset, jotka eivät kuulu omistajaryhmään tai eivät ole tiedoston omistajia.[1]

Tiedosto- ja hakemisto-oikeudet voidaan esittää joko lukuihin perustuvalla esitysmuodolla tai selkokielisesti kirjainkoodeilla. Lukuihin perustuvassa esityksessä hakemistolle ja tiedostolle voidaan antaa jokin numero väliltä 0-7, joka kuvaa pääsyoikeuksien tasoa.[1] Oikeuksia asetettaessa käytetään chmod-komentoa, jonka toimintalogiikka on mielestäni varsin selkeä. Tässä eräs käyttöesimerkki komennon käytöstä: chmod 700 kone.jpg Tämä komento siis asettaa tiedostolle kone.jpg seuraavat oikeudet: Omistajalle kaikki oikeudet ja ryhmälle ja muille ei mitään oikeuksia. Tarkemmin oikeuksien asettamisesta voi lukea esimerkiksi lähteestä [1]. Mikäli numeroiden muistaminen ei innosta, voidaan komentoa käyttää myös muodossa chmod u=rwx,go=x kone.jpg (read write execute) ,mikä asettaa omistajalle kaikki oikeudet ja ryhmälle sekä muille suoritusoikeuden. Itse kuitenkin suosin numeroesitystä, sillä se on minusta selkeämpi tapa ilmaista asia, joskin kirjaimille on selkeästi perusteensa.

Tietoturvan näkökulmasta olisi mielestäni järkevintä noudattaa samaa periaatetta, kuin useissa palomuureissa tai muissa vastaavissa ACL:ään (Access Control List) perustuvassa pääsynvalvontajärjestelmässä, eli lähtökohtaisesti ensin kieltää kaiken ja vasta tämän jälkeen alkaa tarkastella, mitkä oikeudet ovat tarpeellisia. Järjestelmän suojaustaso onkin syytä miettiä alustavasti jollain tasolla jo ennen asennusta, jotta konfigurointi on johdonmukaista. Itse pidän aivan järkevänä vaihtoehtona sitä, että oletusarvoisesti omistajalle annetaan omiin tiedoistoihin täydet oikeudet ja vastaavasti kaikki muut oikeudet kielletään ryhmältä ja muilta, mutta tarpeen mukaan varmasti muitakin "järkeviä" vaihtoehtoja on, mutta koska tässä työssä asiaa pitää tarkastella tietoturvanäkökulmasta, niin turvallisin vaihtoehto on ehdottomasti edellä esittämäni ratkaisu.

UNIX-pohjaisissa järjestelmissä on olemassa umask-komento, jolla voidaan määritellä joko käyttäjälle tai järjestelmälle oletusoikeudet, jotka annetaan jokaiselle luodulle tiedostolle tai hakemistolle. umask toimii siten, että esimerkiksi käyttäjä antaa komennon umask 077, joka tarkoittaa käytännössä sitä, että jokaiselle luotavalle tiedostolle annetaan vastaavat oikeudet, kuin mitä komento chmod 700 tuottaisi. Eli umaskin avulla ikään kuin kerrotaan, kuinka paljon oikeuksia vähennetään täysistä oikeuksista. Edellä mainittu komento ei siis vähennä omistajalta mitään oikeuksia, mutta ryhmältä ja muilta otetaan kaikki oikeudet pois. Nämä asetukset voidaan määritellä /etc/profile -tiedostossa, mikäli halutaan tehdä koko järjestelmän laajuinen konfigurointi.[3]

Lisäksi suoritettaville tiedostoille voidaan asettaa myös lisäominaisuutena set-UID, set-GID tai ns. sticky bit. Jos UID asetetaan, tarkoittaa tämä sitä, että suoritettava tiedosto ajetaan sen omistajan oikeuksilla. Vastaavasti GID tarkoittaa ryhmän oikeuksien antamista suorittajalle. Sticky bitin avulla voidaan käskeä järjestelmää jättämään ohjelman "kuvan" (image) muistiin, jolloin ohjelman käynnistys nopeutuu. Tätä käytetään kuitenkin harvoin, ja tärkeämpää olisikin pyrkiä ohjelman koodin parantamiseen, kuin tämän option käyttämiseen.[3] Ohessa esimerkki, miten näitä käytetään: chmod 4755 progpt2, laittaa UID:n päälle ja antaa tiedostolle 755 oikeudet, chmod 2755 progpt2, muuten sama, mutta nyt GID päällä. Sticky bit menee päälle komennolla chmod 1755 progpt2.[3]

Tiedosto-oikeudet

Chattr ja lsattr sekä niiden käyttäminen

EXT2-tiedostojärjestelmässä, ja sitä uudemmissa, on olemassa lisäattribuutteja, joita voidaan käyttää tietoturvallisuuden parantamiseksi. Näitä attribuutteja voidaan asentaa chattr-komennolla. Tärkeimpiä attribuutteja ovat mielestäni ainakin seuraavat: S, a, i, s ja U. S-attribuutin asettaminen aiheuttaa sen, että tiedosto synkronisoidaan fyysisen tallennusvälineen kanssa, mikä pidemmällä aikavälillä parantaa tiedon eheyttä, tosin nopeuden kustannuksella.[3] Seuraavaksi tarkastellaan a-attribuuttia. Tämä tarkoittaa sitä, että tiedoston loppuun voidaan vain lisätä jotain tekstiä. Tämä ominaisuus on hyödyllinen esimerkiksi lokitiedostoissa, sillä mahdollisen hyökkääjän on vaikeampi peittää omia toimiaan, koska lokitiedostojen peukalointi vaikeutuu [3]. Toisaalta jos hyökkääjällä on root-käyttäjän oikeudet, ei tämän suojauksen kiertäminen ole ollenkaan vaikeaa, mikäli ylläpitäjä ei ole huomannut tehdä tiettyjä toimia järjestelmän suojaamiseksi [3]. Näistä toimista lisää myöhemmin.

I-attribuutin asettaminen on hyvin oleellista tietoturvan kannalta, joskin tätä ominaisuutta pääasiassa voidaan käyttää vain käyttäjän omien toimien estämiseen, ikään kuin suojakeinona. Immutable-attribuutti siis estää tiedoston poistamisen, myös pääkäyttäjältä. Uusia linkkejä, jotka osoittavat suojattuun tiedostoon, ei voida enää tehdä. Ylläpitäjä voi siis suojata järjestelmän kannalta tärkeitä tiedostoja poistamiselta, eli kyseessä on todellakin lähinnä suoja käyttäjän vahinkoja vastaan. Hyökkääjältä, jolla on pääkäyttäjän oikeudet, tuskin menee kovin pitkään keksiä, jos jollekin tiedostolle on asetettu tämä ominaisuus, jonka hän myös pystyy tarvittaessa helposti poistamaan, mikäli tiettyjä turvatoimia ei ole tehty.[3] Tarkastellaan vielä kahta muuta ominaisuutta, eli s- ja U-attribuutteja. U-attribuutilla varustetun tiedoston poistaminen tosiasiassa siirtää tiedoston toisaalle, josta se on mahdollista palauttaa. Kyseessä on siis eräänlainen undelete-toiminto. Viimeinen, eli s-attribuutti, puolestaan kirjoittaa poistettavan tiedoston ylitse nollia.[3]

Komento lsattr vain listaa nämä erikoisattribuutit, jotka eivät näy normaalissa listauksessa ls-komentoa käytettäessä.

Jotta järjestelmä tai sen tiedostot voidaan suojata täysin tunkeutujalta käyttämällä joko append-only tai immutable-attribuuttia, on syytä poistaa mahdollisuus muuttaa kertaalleen asetettuja suojauksia. Tähän voidaan käyttää lcap-sovellusta ((http://snort-wireless.org/other/lcap-0.0.6.tar.bz2.), jonka avulla tarvittava toimenpide voidaan suorittaa. Suorittamalla komennot ./lcap CAP_LINUX_IMMUTABLE ja ./lcap CAP_SYS_RAWIO. Ensimmäinen komento estää append-onlyn muuttamisen ja jälkimmäinen kieltää raa’an IO-datan käsittelyn.[5]

Ryhmäoikeuksien käyttäminen pääsynvalvonnan apuna

Ryhmien luominen ja ACL:n idea lyhyesti

Fedora Core 6, kuten suurin osa uudemmista Red Hat -pohjaisista Linuxeista, tekee oletuksena jokaiselle käyttäjälle saman nimisen yksityisen ryhmän, joka on käyttäjän oletusryhmänä. Kun järjestelmässä on satoja tai tuhansia käyttäjiä, voi ryhmien hallinta olla vaikeaa. Onkin perusteltua kysyä, onko järkevää luoda jokaiselle käyttäjälle oma ryhmä, vai voisivatko käyttäjät oletusarvoisesti kuulua vaikkapa ryhmään users. Tietoturvan näkökulmasta luonnollisesti on varmastikin paras vaihtoehto, että jokaisella käyttäjällä on oletusarvoisesti yksityinen ryhmä, sillä tällä voidaan vaikeuttaa inhimillisistä erehdyksistä johtuvia vahinkoja, jolloin ryhmälle onkin annettu liikaa oikeuksia. Edellä mainitussa tapauksessa jokainen users-ryhmään kuuluva saattaisi päästä tarkastelemaan jonkin toisen käyttäjän tiedostoja, ja mahdollisesti arkaluontoista tietoa saattaisi päätyä vääriin käsiin.

Joskus on kuitenkin tilanteita, jolloin tiettyjen henkilöiden on päästävä käsiksi samoihin hakemistoihin tai tiedostoihin. Esimerkiksi web-sivujen päivittäminen saattaisi olla tällainen tilanne. Linuxiin voitaisiin luoda erikseen ryhmä webmaster, johon sitten voitaisiin lisätä tietyt käyttäjät. Luonnollisesti on syytä muistaa, että oletuksena jokaisen käyttäjän luoma tiedosto saa FC6:ssa oletusryhmäksi ko. käyttäjän yksityisen ryhmän, joka on siis sama kuin hänen käyttäjätunnuksensa.[3] Ongelmaan on toki monia erilaisia ratkaisumalleja, mutta itse näkisin viisaimpana käyttää jo aikaisemmin kerrottua S-GID:tä ko. hakemistoon, johon tiedostoja luodaan. Näin oletusarvoisesti tiedostoille sovelletaan ryhmän oikeuksia, joten ongelmaa ei synny.[3]

Mikäli halutaan, että webmaster-ryhmän jäsenet saavat muokata esimerkiksi /www/public/htdocs -hakemistoa, niin hakemiston ryhmäomistajuus tulisi vaihtaa sellaiseksi, että vain webmaster-ryhmän jäsenillä on tarvittavat oikeudet ko. hakemistoon. Omistajuuksia voidaan muuttaa käyttämällä esimerksi chown- tai chgpr-komentoja. Muutetaan hakemiston ryhmäomistajuus komentamalla esimerksi seuraavasti: chown :webmaster /www/public/htdocs.[3] Tällaisen ryhmän tulee olla tietenkin luotuna. Ryhmiä voidaan luoda komennolla groupadd. SGID saadaan päälle tuttuun tapaan komentamalla chmod 2770 /www/public/htdocs, joka siis asettaa SGIDin päälle ja antaa omistajalle ja ryhmälle täydet oikeudet, kuten saatamme tiedostojen oikeuksien esittelystä muistaa.

Unix-järjestelmässä tiedostojärjestelmiä voidaan liittää ja poistaa käytöstä käyttämällä mount-komentoa. Mount-komento mahdollistaa myös tietoturvan kannalta oleellisia asioita, kuten suorituksen rajoittamisen, pelkän lukuoikeuden myöntämisen jne. Myös tiedostojärjestelmien liittämisen kieltäminen voidaan nähdä tietoturvan kannalta hyvänä asiana. Normaalikäyttäjää voidaan estää liittämästä esimerkiksi levykettä tai cd-levyä, joten näille medioille kopioiminen ei tällöin onnistu. Mount-komento sisältää myös melko monipuolisia vaihtoehtoja pääsynvalvonnan näkökulmasta, koska parametreina voidaan käyttää esimerkiksi ryhmää, jonka perusteella joko sallitaan tai kielletään tiedostojärjestelmän liittäminen.[5] Vastaavasti esimerkiksi tiedostojen suorittaminen voidaan kieltää tietyltä liitetyltä levyjärjestelmältä kokonaan käyttämällä noexec-lippua. Tämä on erittäin hyödyllinen toimenpide sellaisille liitoskohdille, jotka sisältävät sellaista tietoa tai tiedostoja, joita ei ole missään vaiheessa edes tarkoitus suorittaa. Tällaisia liitoskohtia voivat olla esimerkiksi /var/log tai /tmp. Liittämällä näihin liitoskohtiin oma levyosionsa noexec-lipulla varustettuna varmistutaan siitä, että mahdollinen hyökkääjä ei pysty hyödyntämään näille osioille piilottamaansa troijalaista [5]. Vastaavasti voidaan kieltää S-UID:n tai G-ID:in käyttö nosuid-lipulla. Mountin avulla voidaan myös päättää, käytetäänkö EXT2:sen mukanaan tuomaa ACL-pääsynvalvontaa vai ei.

POSIX ACL:ien käyttäminen on järkevää, kun halutaan varmistaa tehokkaampi pääsynvalvonta, erityisesti useiden käyttäjien järjestelmissä. ACL:n käytöllä voidaan välttää tarpeettomien ryhmien luominen, joten tästä näkökulmasta on hyvä perehtyä lyhyesti järjestelmän käyttöön. ACL:iä voidaan määritellä sekä käyttäjille, että ryhmille ja pääsynvalvonta perustuu perinteiseen luku-, kirjoitus- ja suoritusoikeuksien jakamiselle.[5]

ACL-tuki pitää olla käännettynä Linuxin ytimeen, joten jos ydin pitää kääntää uudelleen, on tärkeää huomioida, että oikeanlaiset valinnat on asetettu. ACL:iä hallitaan käyttämällä setfacl-komentoa, jonka avulla voidaan asettaa, muuttaa tai poistaa asetettuja sääntöjä.[5] Vastaavasti getfacl-komento listaa tiedoston tai hakemiston ACL:t Käyttöesimerkit-osioon tulee esimerkki, kuinka ACL:iä tehdään ja käytetään.

Lisäksi Red Hat -pohjaisissa jakeluissa on mahdollista käyttää User Private Groups -toimintoa. UPG helpottaa UNIX-ryhmien hallintaa. UPG luodaan automaattisesti aina kun käyttäjä lisätään systeemiin. Tällöin luodun UPG:n nimi on sama kuin käyttäjän tunnus ja käyttäjä on ainut jäsen tässä ryhmässä. Kun halutaan antaa usealle käyttäjälle samat oikeudet esimerkiksi tiettyihin tiedostoihin, tämä on helpoin toteuttaa UPG:n avulla. UPG -ryhmiä hallitaan umask -komennolla, jonka käyttö on ylempänä jo selitetty. Myös ryhmän sisällä voidaan antaa eri oikeuksia käyttäjille, mikä tuo lisää tasoja käyttöoikeuksiin ja niiden hallintaan. [7]

Järjestelmäryhmät ja suojausmekanismit

Unix-järjestelmät käyttävät useita ryhmiä jonkin toiminnon suorittamiseen. Esimerkiksi automaattisesti järjestelmässä on yhteensopivuuden takaamiseksi joitain jo hyvin harvinaiseksi käyneitä ryhmiä kuten uucp, joka oli aikanaan tarpeellinen väline, kun käytettiin Unix-to-Unix -kopiointia. Nykyään vastaavaa toimintaa varten on jo parempia tapoja, kuten FTP-siirto.[3] Vastaavasti voidaan käyttää ryhmää cdrom, jonka avulla voidaan hallita optisten asemien hallinnointia. Järjestelmässä on mahdollista estää esimerkiksi kirjoittavien cd-asemien tai myös kaikkien cd-asemien käyttö, mikä voi olla ihan hyvä ratkaisu tietoturvan näkökulmasta tietyissä ympäristöissä. Useimmissa järjestelmissä (kotikäytössä) nämä ryhmät kuitenkin ovat käytössä, mikä onkin useimmiten ihan perusteltua ja järkevää.

Järjestelmässä on myös sellaisia ryhmiä, jotka ovat toiminnan kannalta oleellisia. Tällaisia ovat esimerkiksi sys, bin, adm, sshd, daemon, kmem jne. Tavallisen käyttäjän ei luonnollisestikaan tarvitse näistä välittää, sillä ryhmät liittyvät järjestelmän sisäisiin toimintoihin, useimmiten kyseessä on jokin palvelu tai muu vastaava.

Järjestelmän suojausmekanismit

Sudo-työkalua voidaan mielestäni käyttää myös monella tapaa pääsynvalvonnassa, kun halutaan antaa käyttäjille tiettyjä oikeuksia suorittaa joitakin rajoitettuja toimintoja. Suorittamalla pääkäyttäjänä komento visudo päästään konfiguroimaan, ketkä voivat käyttää sudoa ja mihin sitä sovelletaan. Oikein käytettynä sudo on erittäin hyvä työkalu, kun halutaan sallia esimerkiksi tiettyjen käyttäjien ajavan jotain prosessia toisena käyttäjänä. Asetustiedostoon voidaan esimerkiksi kirjoittaa seuraavanlainen konfiguraatio:
User_Alias ADMINS=kale,jimi,tuukka
User_Alias WEBMASTERS=sini,loviisa
Runas_Alias DAEMONS=bind,www,smmsp,ircd
Host_Alias WEBSERVERS=www.eipysty.com,www.liian.hapokasta.com,www.colaolli.com
Cmnd_Alias PROCS=/bin/kill,/bin/killall,/usr/bin/skill,/usr/bin/top
Cmnd_Alias APACHE=/usr/local/apache/bin/apachectl
WEBMASTERS WEBSERVERS=(www) APACHE
ADMINS ALL=(DAEMONS) ALL 
%webmaster WEBSERVERS=(www) APACHE

Viimeisin rivi antaa jokaiselle käyttäjälle, joka kuuluu ryhmään webmaster, pääsyn WEBSERVERS-aliaksessa määriteltyihin osoitteisiin, jossa käyttäjä voi ajaa APACHE-aliaksessa määritellyn komennon käyttäjänä www. Tällaisia konfiguraatioita käyttämällä voidaan tarjota monipuolisia käyttö- ja pääsyoikeuksia ilman, että pääkäyttäjän salasanaa tarvitsee antaa jokaiselle käyttäjälle, tai yleensäkään kenellekään, johon ei voi täysin luottaa. Tarvittavien oikeuksien jakaminen hyvällä konfiguraatiolla on tehokasta ja ennen kaikkea tietoturvallista. Vastaavasti saattaisi olla perusteltua antaa esimerkiksi helpdesk-ryhmään kuuluville käyttäjille oikeus passwd-komentoon siten, että he pystyvät vaihtamaan kaikkien muiden salasanoja, paitsi pääkäyttäjien. Tällöin unohtuneiden salasanojen vaihto onnistuisi melko vaivattomasti ja pääkäyttäjän ei tarvitsisi edelleenkään antaa näille henkilöille muita oikeuksia. Vähimmän oikeuden periaate siis toteutuisi tässäkin tapauksessa.[5]

Wheel-ryhmä

Wheel-ryhmän käyttäminen lisää kontrollointimahdollisuuksia pääsynvalvonnan näkökulmasta. Tämän ryhmän tarkoituksena on säädellä pääkäyttäjän oikeuksien saamista. Ryhmää käytetään siten, että su –komennon pystyvät ajamaan vain wheel-ryhmässä määritellyt henkilöt. Normaalisti su –komento olisi kaikkien käytettävissä. Tällainen rajaus on jo merkittävä parannus tietoturvan näkökulmasta, sillä tavallisen käyttäjätunnuksen murtaminen ei vielä mahdollista su –komennon käyttöoikeutta. Ryhmän käyttäminen järjestelmässä on erittäin perusteltua, koska pienellä vaivalla saadaan merkittäviä parannuksia aikaan tietoturvallisuuden näkökulmasta ajateltuna.[6]

Rajoitetut käyttäjätilit

Joidenkin käyttäjien ei välttämättä tarvitse päästä käsiksi muuhun järjestelmään, vaan heille saattaa riittää pelkästään yhden ohjelman ajaminen. Järjestelmä tarjoaa captive-tunnuksen, jolloin ajettava ohjelma korvaa normaalin komentotulkin, kuten bashin tai zsh:n. Rajoitetut käyttäjätunnukset tallennetaan /etc/passwd –tiedostoon, aivan kuten muutkin tunnukset. Tällainen järjestely toimii siten, että kun käyttäjä kirjautuu järjestelmään, ohjelman suoritus alkaa välittömästi ja vastaavasti kun suoritus loppuu, käyttäjä kirjataan ulos järjestelmästä. Käyttäjällä ei siis ole mitään mahdollisuuksia päästä vahingoittamaan järjestelmää.[6]

Valitettavasti kaikkia ohjelmia ei pystytä käyttämään tällä tavoin. Jos käyttäjän on syötettävä jokin muuttuja, niin joissain tapauksissa tällainen järjestely ei välttämättä toimi. Tätä tilannetta varten UNIX-järjestelmissä on käytössä rsh, eli restricted shell. Rajoitetussa komentotulkissa ei ole mahdollista ajaa ”vaarallisia” komentoja, eli niitä, joita normaalissa ympäristössä on mahdollista suorittaa. Esimerkiksi komento cd on poistettu, joten käyttäjä ei pysty poistumaan kotihakemistostaan. Käyttäjällä on siis käytössään vain tarvittavat komennot jonkin tietyn spesifisen asian tekemiseen.[6]

Yksi vaihtoehto olisi myös lisätä käyttäjän sisäänkirjautumisen yhteydessä ajettaviin komentoihin suoritettavan ohjelman käynnistävä komento (ns. login script), jonka päätteeksi suoritetaan esimerkiksi logout-komento. Tällainen ratkaisu ei kuitenkaan ole tietoturvan näkökulmasta paras mahdollinen, sillä kokenut käyttäjä voi yrittää kiertää skriptin sisäänkirjautumisen yhteydessä.[6]

Käyttöesimerkki, ACL:n luominen

Luodaan ensin tiedosto spede komennolla touch spede.

Tämän jälkeen tehdään ACL seuraavasti:
setfacl –m u:raine:rx,g:admins:rwx,o:--- spede

Tämän jälkeen voidaan tarkastella listausta komennolla getfacl spede. Listaus on seuraavanlainen:
# file: spede 
# owner: root 
# group: root 
user::rw- 
user:raine:r-x 
group::r-- 
group:admins:rwx 
mask::rwx 
other::--- 

Jos vaihdetaan maskia esimerkiksi seuraavaan muotoon, niin saadaan toisenlaiset ACL:t voimaan.
setfacl –m m:r-- spede
getfacl spede
# file: spede 
# owner: root 
# group: root 
user::rw- 
user:raine:r-x             #effective:r-- 
group::r-- 
group:admins:rwx       #effective:r— 
mask::r-- 
other::--- 

Security Enchanced Linux

Useimmista tämän päivän käyttöjärjestelmistä puuttuu kriittinen turvaominaisuus, jota tarvitaan järjestelmän turvallisuuden kannalta monissa asioissa. Tämä ominaisuus tunnetaan paremmin MAC:ina (Mandatory Access Control), eli pakollisena pääsynvalvontana. Tämän seurauksena sovelluksien turvallisuusmekanismit ovat alttiita peukaloinnille ja ohittamiselle, ja haittaohjelmat tai vialliset sovellukset voivat heikentää järjestelmän tietoturvallisuutta merkittävästi. [2] SELinux korjaa tämän ongelman, eli se perustuu MAC:hen, joka toteutetaan käyttämällä Linux Security Moduleita (LSM), jotka toimivat Linuxin ytimessä. Näiden käyttö perustuu vähimmän oikeuden periaatteeseen.[4] SELinuxin käyttö perustuu tietynlaisten politiikkojen käyttöön, joita voidaan soveltaa monipuolisesti juuri ko. järjestelmän turvallisuuteen. SELinux asentuu oletuksena sellaisella politiikalla, joka on melko yleiskäyttöinen ja toimii useimmiten riittävän hyvin normaalikäyttäjän näkökulmasta. Asiaan vihkiytynyt voi kuitenkin muokata politiikastaan sellaisen kuin haluaa.[2]

MAC:n ja DAC:n pääasiallinen ero on siinä, että MAC:ia käytettäessä järjestelmänvalvoja määrittelee, missä rajoissa käyttäjä voi asettaa oikeuksia luomilleen tiedostoille tai muille hallitsimilleen resursseille. Tämä tarkoittaa siis sitä, että käyttäjä ei esimerkiksi pysty asettamaan kirjoitusoikeuksia vaikkapa ryhmälle, jos pääkäyttäjä on politiikassaan näin määritellyt. Käyttäjä ei siis pysty asettamaan vähemmän rajoittavia oikeuksia, mitä politiikassa on. DAC:ssa taas käyttäjä voi halutessaan antaa hallussapitämiään oikeuksia kenelle tahansa. Eli jos käyttäjä on tiedoston omistaja ja hänellä on siihen kaikki oikeudet, voi hän halutessaan sallia myös muille ryhmille vastaavantasoiset oikeudet.

SELinux käyttää yleispolitiikassaan perusteenaan sellaisia pääsynvalvontakäytäntöjä, jotka perustuvat MLS:ään, RBAC:hen sekä TE:hen. SELinux tarjoaa vain sellaisia vaihtoehtoja politiikassaan, jotka kieltävät jonkin asian, eli kyseessä on vain rajoituksia sisältävä järjestelmä. Se ei myöskään mahdollista minkään toiminnan suorittamista, jonka Unixin oikeudet kieltävät.[4]

AIDE, LIDS ja Tripwire

Kirjallisuutta tutkiessa satuin törmäämään LIDS:ään, joka on siis Linux Intrusion Detection System, jonka toimintaperiaate vaikutti varsin mielenkiintoiselta. www.lids.org tarjoaa kiinnostuneille lisätietoa. Kyseinen järjestelmä varmasti tukisi omalta osaltaan SELinuxin ominaisuuksia. AIDE, eli Advanced Intrusion Detection System on suomalainen projekti, joka pohjautuu Tripwire-ohjelmaan. Kyseessä on tiedostojen ja hakemistojen eheyttä valvova ohjelma, jonka toimintaperiaatteena on luoda tiedosto- ja hakemistorakenteesta eräänlainen tietokanta, johon tallennetaan allekirjoitus jokaisesta tiedostosta ja hakemistosta. Ohjelmaa voidaan soveltaa esimerkiksi niin, että palvelimen asennuksen yhteydessä luodaan tietokanta cd-rom –levylle, jolloin varmistutaan siitä, ettei tietokanta ole mahdollinen muutoksille. Mikäli jokin tiedosto on muuttunut esimerkiksi tietomurron yhteydessä, ohjelma löytää muuttuneet tiedostot tai hakemistot, koska allekirjoitus ei täsmää tietokantaan. Lisätietoja kiinnostuneille seuraavista linkeistä:

 
Tripwire: http://www.tripwire.com/products/enterprise/ost/

AIDE: http://www.cs.tut.fi/~rammer/aide.html

LIDS: www.lids.org

Päätelmät

Tietoturvallisuus UNIX-käytössä on ehdottoman tärkeä asia ja järjestelmä tarjoaakin siihen hyvät lähtökohdat, kunhan ylläpitäjä on valveutunut ja viitsii ottaa asioista selvää. Tosiasia on, että todella turvallisen järjestelmän luominen on prosessi, joka vie aikaa ja vaivaa. Turvallisuuden saavuttaminen perustuu mielestäni hyvin olennaisesti juuri pääsynvalvonnan järjestämiseen, sillä tämä on oikeastaan ainoa olennainen lähestymistapa tämän tyyppisissä järjestelmissä, joissa hallintamallina ovat pääasiassa pääsylistat. Myös tiedosto-oikeuksia voitaneen pitää eräänlaisena pääsylistana, sillä siinä selkeästi erotellaan, kenellä on oikeus tehdä jotain.

Tämä työ oli todella opettavainen ja alkuperäisestä suunnitelmasta jouduin hieman tinkimään mm. kokemuksen ja osaamisen puutteen vuoksi. Tämä realisoitui lähinnä kohdassa "käyttöesimerkit", johon en valitettavasti saanut oikein mielekkäitä tulosteita, paitsi ACL:n luominen. Toivottavasti tästä työstä on jonkinlaista hyötyä myös muille opiskelijoille. Omasta mielestäni näillä eväillä on hyvä lähteä rakentamaan tietoturvallista Linux-palvelinta, joskin lisätietoa on hyvä etsiä omatoimisesti

Lähteet

[1] Linux.fi Wiki-sivustot http://linux.fi/index.php/Tiedoston_oikeudet (viitattu 6.11)

[2] National Security Agency http://www.nsa.gov/selinux/ (viitattu 6.11.2006)

[3] Kabir, M. J., : Red Hat Linux Security and Optimization, Hungry Minds Inc., 2002

[4] http://en.wikipedia.org/wiki/SELinux (viitattu 13.12.2006)

[5] Lockhart, A. : Network Security Hacks, O'Reilly, 2006

[6] Levi, B. : UNIX Administration - A Comprehensice Sourcebook for Effective Systems and Network Management, CRC Press

[7] Red Hat Linux 9: Red Hat Linux Reference Guide http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-users-groups-private-groups.html (viitattu 16.11.2009)

Print version |  PDF  | History: r3 < r2 < r1 | 
Topic revision: r3 - 16 Nov 2009 - 23:33:25 - JuusoPiskonen
 

TUTWiki

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TUTWiki? Send feedback