Käyttöjärjestelmien turvallisuusperiaatteet ja -mallit¶

Koska käyttöjärjestelmät ja/tai hypervisorit ovat perusta turvallisuudelle niin suurelle osuudelle tietojärjestelmistä, niiden suunnittelua koskeva keskustelu viittaa usein turvallisuusperiaatteisiin ja -malleihin. Edellisiä käsiteltiin melko laajasti jo materiaalin alussa. Siellä olevaan käsitekarttaan viitataan seuraavassa alaluvussa yleisesti ja suhteessa erityyppisiin käyttöjärjestelmiin. Sitä seuraava alaluku esittää lyhyen johdannon turvamalleihin. Sellaisten laajempi tarkastelu kuuluu (myöhemmillä kursseilla) pääsynvalvonnan piiriin. Tässä sen käsittely on motivoitu, koska pääsynvalvonta usein palautuu siihen, mitä käyttöjärjestelmä tekee.

Yksi keskeinen käsite on syytä määritellä tässä vaiheessa. Jos ajatellaan tietojenkäsittelyjärjestelmää siinä olevien tietojen omistajan ja hänen asettamansa tietoturvapolitiikan kannalta, TCB, trusted computing base, kuvaa sitä aluetta, jonka sisäpuolella politiikan voidaan uskoa toteutuvan “automaattisesti”. Se on siis luotetun tietojenkäsittelyn tukikohta, base. Siihen kuuluu laitteiston lisäksi nimenomaan osia käyttöjärjestelmästä ja tässä yhteydessä TCB viittaa nimenomaan koodiin. Luottamusta käsittelevän luvun käsitekartta (jälkimmäinen kahdesta) esittää luotetun tietojenkäsittelyn piirteitä. On hyvä myös huomata, että se mitä tässä luvussa kutsutaan suojausalueeksi (security domain) vastaa käsitekartan mainitsemaa luottamusaluetta. Termiä TCB ei ole tapana kääntää suomeksi.

Turvallisuusperiaatteet (syventävä)¶

Turvallisuuden näkökulmasta eri suojausalueiden välissä pitäisi olla mahdollisimman täydellinen eristys (käsitekartassa “käytä rakenteita → eristys”). Kaiken suojausalueiden välisen vuorovaikutuksen tulee olla täydellisesti välitettyä eli tarkistettua (kartassa: “Salli vähemmän → tarkista ennen luottamista”). Suojausalueilla tulisi olla mahdollisimman vähän yhteisiä mekanismeja – varsinkaan sellaisia, joissa on yhteisiä tilatietoja (“Minimoi → yhteisten välineiden määrä”). Jos esimerkiksi voidaan valita tietyn proseduurin osalta, lisätäänkö se käyttöjärjestelmän ytimeen globaaleilla muuttujilla vai pannaanko se saataville käyttäjätilan kirjastossa, joka toimii eristetyllä tavalla jokaisessa prosessissa, pitäisi valita jälkimmäinen vaihtoehto. Se ei kuitenkaan saa lisätä koodin kokoa liikaa tai rikkoa muita periaatteita tai rajoituksia. Lisäksi välityksen tulee noudattaa turvallisten oletusarvojen periaatetta. (“Salli vähemmän → oletuksena kielto”). Esimerkiksi politiikka, jolla suojausalueita päästetään käyttämään toistensa resursseja, ei saa olla tyypiltään “kyllä, paitsi jos” vaan sen pitää olla “ei, paitsi jos (on täsmällinen valtuutus)”. Yhteisten mekanismien minimoinnin lisäksi mekanismin taloudellisuuden periaate (“minimoi → mutkikkuus”) tarkoittavat, että pitäisi minimoida luottamusta edellyttävän koodin TCB-koodin määrä (“minimoi → turvapalikat (luotettu koodi; kovo)”). Tutkimukset ovat osoittaneet, että jopa hyvät ohjelmoijat tuottavat 1–6 virhettä 1000 koodiriviä kohden. Jos koodin mutkikkuus ei muutu, TCB:n pienentäminen tarkoittaa vähemmän bugeja, pienempää hyökkäyspintaa ja parempia mahdollisuuksia tarkistaa automaattisesti tai manuaalisesti TCB:n oikeellisuus muodollisen määrityksen suhteen.

Aiemmassa alaluvussa esiteltiin neljä käyttöjärjestelmän rakennetyyppiä:

yhden suojausalueen tapaus
monoliittinen järjestelmä
monipalvelinjärjestelmä
kirjastokäyttöjärjestelmä

Tapaus 1 tarkoittaa, että TCB sisältää kaikki järjestelmän ohjelmistot, mukaan lukien sovellukset. Kaikki mekanismit ovat “yhteisiä”, eikä turvallisia oletusarvoja tai tarkistuksia ole käytännössä lainkaan. Monoliittisen käyttöjärjestelmän suunnittelussa tilanne on hieman parempi, sillä ainakin käyttöjärjestelmä on suojattu sovelluksilta ja sovellukset toisiltaan. Itse käyttöjärjestelmä on kuitenkin edelleen yksi suojausalue, joka perii tapauksen 1 haitat. Usean palvelimen käyttöjärjestelmän (tapaus 3) äärimmäinen osastointi (“← eristäminen ← käytä rakenteita”) soveltuu tapausta 2 paremmin turvallisuuden varmistamiseen: voimme pakottaa tarkistukset komponenttien välillä pienikokoisessa mikroytimessä, jossa on turvallisia oletuksia. Suuri osa koodista, joka muissa malleissa on käyttöjärjestelmän suojausalueella, kuten ohjaimien koodi, ei ole enää osa TCB:tä. Unikernelit (tapaus 4) ovat mielenkiintoinen vaihtoehto: periaatteessa käyttöjärjestelmän koodi ja sovellus toimivat samassa suojausalueessa, mutta libOS-koodi on mahdollisimman pieni ja eri sovelluksille yhteinen mekanismi on minimoitu (“→ turvapalikat”). Resurssien osastointi voidaan myös toteuttaa kokonaan Unikernel-tasolla. Unikernel-sovelluksessa TCB koostuu vain pohjalla olevasta hypervisorista/Exokernelistä ja käyttöjärjestelmäkomponenteista, joita sovellus haluaa käyttää. Lisäksi käyttöjärjestelmäkomponentin toteuttava kirjasto on vain tämän sovelluksen TCB:ssä, koska muut eivät jaa sitä.

Avoimen suunnitelman (open design) periaate voi olla edellä mainittuja kiistanalaisempi. (Kartassakaan “organisoi työsi → avoin rakenne” ei kuulu korkeimman tason periaatteisiin.) On käyty loputtomia keskusteluja erityisesti avoimesta lähdekoodista, joka on yksi tapa noudattaa periaatetta. Sitä on verrattu suljettuun lähdekoodiin ja on kiistelty eduista ja haitoista turvallisuuden kannalta. Avoimen rakenteen etuna on, että kuka tahansa voi tutkia sitä, mikä lisää todennäköisyyttä löytää vikoja yleensä ja haavoittuvuuksia erityisesti. Auguste Kerckhoffs teki samanlaisen havainnon kryptojärjestelmistä 1800-luvulla, ja se ilmaistaan usein niin, että ei pidä luottaa piiloutumiseen. Loppujen lopuksi piilo paljastuu, ja kun pahikset löytävät sieltä haavoittuvuuden ennen hyviksiä, joudutaan ongelmiin. Vasta-argumentti tälle on, että avoimen rakenteen tapauksessa pahiksilla on suurempi todennäköisyys löytää vika.

Sitä vastoin ei ole epäilystäkään siitä, että tiukasti osastoitu rakenne toteuttaa sekä vähimpien oikeuksien että oikeuksien eriyttämisen periaatteet (“← salli vähemmän”) paremmin kuin sellainen, jossa suurin osa koodista suoritetaan yhdellä suojausalueella. Erityisesti monoliittisessa järjestelmässä ei ole todellista käyttöjärjestelmän eri komponenttien oikeuksien eriyttämistä, ja käyttöjärjestelmä toimii aina kaikilla oikeuksilla. Toisin sanoen käyttöjärjestelmäkoodi, joka vastaa käynnissä olevan prosessin tunnisteesta (pid), voi muokata muistin sivutaulukoita, luoda root-tilejä, muokata mitä tahansa levyllä olevia tiedostoja, lukea ja kirjoittaa mielivaltaisia verkkopaketteja ja kaataa koko järjest elmän aina kun se parhaaksi näkee. Monipalvelinjärjestelmät ovat hyvin erilaisia. Ne voivat rajoittaa käyttöjärjestelmän kullekin komponentille mahdolliset kutsut vain niihin, joita se tarvitsee tehtäväänsä (“vähimmät oikeudet”). Myös oikeuksien eriyttäminen siis toteutuu komponenttien välillä. Unikernelit, eli kirjastokäyttöjärjestelmät tarjoavat erilaisen ja mielenkiintoisen mahdollisuuden käsitellä tätä ongelmaa. Vaikka useimmat komponentit toimivat yhdessä toimialueessa, siis ilman eriytystä tai oikeuksien minimointia, käyttöjärjestelmä on purettu vain sovelluksen suorittamiseen tarvittaviin osiin, ja itse Unikernel voisi toimia vain tähän tarkoitukseen vaadituilla oikeuksilla.

Olipa turvallisuus kuinka tärkeä tahansa, psykologisen hyväksyttävyyden periaate (“sovella … → käyttäjäkokemus → …”) sanoo, että järjestelmän pitäisi olla silti käyttökelpoinen. Käyttöjärjestelmän turvallisuuden monimutkaisuuden vuoksi tämä ei ole triviaalia. Vaikka suojatut käyttöjärjestelmät, kuten SELinux (security enhanced Linux) ja QubesOS, tarjoavat selkeitä turvallisuusetuja moniin muihin käyttöjärjestelmiin verrattuna, harvat tavalliset käyttäjät käyttävät niitä ja vielä harvemmat tuntevat olonsa varmaksi määrittäessään suojausasetukset itse.

Turvamallit (syventävä)¶

Tärkeä kysymys käyttöjärjestelmissä koskee tiedonkulkua: kuka saa lukea ja kirjoittaa mitä dataa? Perinteisesti järjestelmän laajuiset käytännöt määritetään turvamalleilla. Niiden lähtökohtana ovat tiedon erilaiset turvatarpeet ja niistä muodostuvat rakenteet. Tarkastellaan tässä vain sellaista rakennetta, jossa on eri tasoja (multilevel security, MLS). Lisäksi voitaisiin huomioida eri toimialueita (multilateral security). Sotilasperinteessä tasojaottelu voi olla esim: “unclassified”, “classified”, “secret”, “top secret” jne. Liiketoiminnassa voisi olla “julkinen”, “luottamuksellinen”, “salainen”.

Pääsynvalvonnan ryhmittelyrakenteen soveltaminen erityisesti sotilassovelluksissa lähtee liikkeelle “need-to-know” -periaatteesta, jossa kullekin pyritään järjestämään pääsy vain sellaiseen tietoon, joka on tarpeen tehtävien hoitamiseksi (kartassa “Salli vähemmän→…→pakko tietää”). Sekä toimijat että kohteet varustetaan turvamerkinnöillä (tai turvanimiöillä, labels), joita toimijoiden tapauksessa voidaan kutsua oikeuksiksi (clearance) ja kohteiden tapauksessa luokituksiksi (classification). Yleisesti kyseessä on näiden olioiden enemmän tai vähemmän pysyvistä attribuuteista.

Tietoresursseja eri tasoille luokittelevien turvamerkintöjen tarkoitus on varsin ilmeinen. Turvamallin toteutus tarvitsee vielä tarkemmat ehdot pääsyä valvovalle viitemonitorille, jotta voitaisiin todeta, että väärät toimijat eivät pääse näkemään tietoa tai “saastuttamaan” sitä, siis sotkemaan sen eheyttä. Perusmallit käsittelevät vain jompaa kumpaa näkökulmaa, luottamuksellisuutta tai eheyttä, vaikka yhdistelmiäkin tietysti tarvitaan. Saatavuus on sen verran hankalampi tavoite, ettei siitä juuri ole malleja.

Luottamuksellisuus¶

Säännöt ovat, että oman tason yläpuolelta ei saa lukea (NRU, “No Read Up”) ja ettei oman tason alapuolelle saa kirjoittaa (NWD “No Write Down”). Nämä ovat keskeinen sisältö mallissa, jonka Bell ja LaPadula kehittivät vuonna 1973. Se onnistui kuvaamaan hyvin sitä, miten turvamerkintöjen käytäntö toimii. Varsinkin NWD-sääntö (ns. *-sääntö, tai confinement rule) oli silti uudistus, koska aikaisemmin ei ollut mallia, joka olisi estänyt tietokoneiden Troijan hevosia vuotamasta tietoja alaspäin. Ilmeisemmästä NRU-säännöstä käytetään myös nimitystä simple security rule. BLP-malli sisältää näiden sääntöjen lisäksi oletuksen, ettei olioiden luokitus muutu operaation aikana. Tämä vaadittava ns. tranquility-ominaisuus (eräänlainen “rauhoitus”) voi toteutua eriasteisena, mutta ilman sitä tietoturvatavoite ei toteutuisi.

Turvaluokituksen purkaminen tai suojaustasojen alentaminen (esim. tietojen kopioiminen huippusalaisesta salaiseen asiakirjaan) voidaan tehdä vain erityisten, “luotettujen” subjektien toimesta. Tämän mallin tiukka noudattaminen estää arkaluonteisten tietojen vuotamisen valtuuttamattomille käyttäjille.

Eheys¶

Jos tavoitellaan eheyttä, voidaan tarvita erilaista luokitusta kuin luottamuksellisuudessa. Oletetaan nyt vain, että jokin tasojaottelu on saatu aikaan. Silloin on helppo huomata, että eheyssäännöt ovat tarkalleen päinvastaiset kuin BLP-mallissa. Tasojen vaatima eheys säilyy, jos noudatetaan sääntöjä NWU, “No Write Up” ja NRD, “No Read Down”. Tämä eheysmalli on pari vuotta nuorempi kuin BLP-malli ja se on nimeltään Biba-malli laatijansa nimen mukaisesti. Se sisältää joitakin variaatioita: Jos NWU- ja NRD-säännöistä pidetään tiukasti kiinni, puhutaan mandatorisesta Biba-mallista. Jos sitä käytetään yhdessä BLP-mallin kanssa eikä eheysluokitusta tehdä erikseen, päädytään siihen, että luku ja kirjoitus on sallittua vain samaan luokkaan kuuluvien olioiden kesken. Toisenlainen mahdollisuus on sallia myös “WU” ja “RD”, mutta näiden tapahtuessa pitää sitten muuttaa ylemmän tason olion (siis kirjoitetun kohteen tai lukeneen toimijan) luokitus alemman tason mukaiseksi. Biba-malli ei sellaisenaan ole ollut kovin käyttökelpoinen. Se ei ollutkaan syntynyt mallintamaan vallitsevia käytäntöjä.

Kymmenisen vuotta Biba-mallia nuorempi on Clarkin ja Wilsonin kehittämä ns. kaupallinen eheysmalli. Siinä on kaksi keskeistä käsitettä: hyvin muodostettu liiketapahtuma (transaktio) ja tehtävien eriyttäminen. Jälkimmäinen on normaali menettely liike-elämässä petosten ehkäisyssä, eikä ole tuntematon sotilaspuolellakaan, esim. ydinaseiden käytössä.

Liiketoimet säilyttävät eheyden, jos ne on pantu kokoon eheyden säilyttävistä muunnoksista, proseduureista. Näiden muunnosten soveltamiseen liittyy pääsynvalvontaa ja erityisesti tehtävien eriyttämistä. Malli ei kuitenkaan tarjoa keinoja ratkaista, mitkä muunnokset ovat eheyttä säilyttäviä. Tässä suhteessa malli ei siis ole sen täydellisempi kuin Biba-mallikaan.

MAC, DAC, RBAC ym.¶

Bell-LaPadula ja Biba ovat pääsynhallinnan malleja, joita käyttöjärjestelmä soveltaa välittäessään pääsyä resursseihin, kuten muistiin tai levyllä oleviin tiedostoihin. Tarkemmin sanottuna ne ovat MAC-malleja (Mandatory Access Control), joissa järjestelmänlaajuinen käytäntö määrittää, millä käyttäjillä on lupa lukea tai kirjoittaa mitäkin asiakirjoja, eivätkä käyttäjät pysty tuomaan tietoja muiden käyttäjien saataville ilman asianmukaista lupatasoa, vaikka se olisi kuinka kätevää. Vähemmän tiukka malli tunnetaan nimellä DAC (Discretionary AC), jossa käyttäjät, joilla on pääsy objektiin, voivat vaikuttaa siihen, kenellä muulla on pääsy siihen. DAC voi esimerkiksi rajoittaa pääsyä objekteihin käyttäjän tai prosessin identiteetin tai ryhmäjäsenyyden perusteella. Vielä tärkeämpää on, että DAC sallii käyttäjän tai prosessin, jolla on käyttöoikeudet objektiin, siirtää nämä oikeudet muille käyttäjille tai prosesseille. Pelkästään tämän ryhmäpohjaisen DAC:n käyttö vaikeuttaa järjestelmän tiedonkulkua jäsennellysti. On kuitenkin mahdollista yhdistää DAC ja MAC antamalla käyttäjille ja ohjelmille vapaus siirtää käyttöoikeuksia muille MAC-käytäntöjen asettamien rajoitusten puitteissa.

Pääsynvalvontaa käsitellään monipuolisesti toisaalla. Tässä yhteydessä kannattaa jo mainita roolipohjainen pääsynvalvonta (role-based access control, RBAC), joka rajoittaa pääsyä objekteihin roolien perusteella, jotka voivat perustua työtehtäviin. Vaikka RBAC on intuitiivisesti yksinkertainen, sen avulla voidaan toteuttaa sekä DAC- että MAC-pääsynhallintakäytäntöjä. Malleja on vielä muitakin. Esimerkiksi Kiinan muuri -malli (Brewer ja Nash, 1989) koskee pääsynvalvonnan sääntöjä tilanteessa, jossa konsulttiyrityksellä on asiakkaina useita muita yrityksiä, joista osa on kilpailijoita keskenään. Tavoitteena on muotoilla tiedon luokitukset ja pääsyoikeudet siten, ettei pääse syntymään sellaista tiedon virtausta, joka aiheuttaa intressien ristiriidan.