TTKK / J.Koskinen / Tietoturvallisuuden perusteet, 2002

Käyttöjärjestelmistä

Sisältö

Käyttöjärjestelmään perinteisesti liittyviä turva-asioita

[1] Tunkeutumisen havaitseminen

[2] Tunkeutumisen havaitsemismenetelmien luokittelua

Näkökulmia luotettuun käyttöjärjestelmään

Käyttöjärjestelmään perinteisesti liittyviä turva-asioita Motivointia Yksinkertaisenkin tietokoneen käyttöjärjestelmällä on tehtäviä, joiden merkitys on tärkeä tietoturvallisuuden kannalta. Kyseessä ovat lähinnä muistin ja prosessien hallinnan rutiinit, joita ei yleensä tulla ajatelleeksi osana tietoturvaa. (Myös tiedostonhallinnalla on vastaavaa merkitystä, mutta sitä ei käsitellä täsä yhteydessä.) Sisältöä ja tavoitetta Katsotaan lyhyesti, mitä keinoja "tavallisella" käyttöjärjestelmällä on pitää prosessi aisoissa, erityisesti miten muistiviittaukset pidetään erossa muiden prosessien käyttämästä muistialueesta. Tavoitekysymyksiä. Näistä jälkimmäinen ensin toistaa ensimmäistä mutta jatkaa sitten eri suuntaan. Kumpikin edellyttää kytkentöjä toisaalla käsiteltyihin aiheisiin. Muihin on luontevaa tutustua ennen tätä jaksoa, mutta TCB-käsitteeseen tämän jälkeen. Millä tavoin käyttöjärjestelmän toteuttamalla muistinhallinnalla (segmentoinnilla, sivutuksella, virtuaalimuistilla yms.) on merkitystä tietoturvan kannalta? Mikseivät tällaiset asiat yleensä ilmene edes alimman tason tietoturvapolitiikassa, joita tietotekniikkaa hyödyntävä yritys laatii? Mitä tekemistä asiassa on käsitteellä 'trusted computing base' (eli TCB)? (a) Mitä merkitystä käyttöjärjestelmän toteuttamilla keskusmuistin ja prosessien hallinnan matalankin tason rutiineilla on tietoturvallisuuden kannalta? (b) Kohdassa a mainitut seikat eivät yleensä tule näkyviin tietoturvapolitiikoissa, mutta tiedostonhallinnasta löytyy sellaisia käyttöjärjestelmän tehtäviä, joita voidaan säännellä politiikkaan kirjattavilla päätöksillä. Keksi kaksi esimerkkiä. (c) Myös a-kohdassa mainittu prosessien hallinta tulee tietoturvapolitiikan piiriin, jos sitä katsotaan hieman korkeammalta tasolta, esim. sellaiselta, jossa lokitiedostoja kirjoitetaan. Millaisia päätöksiä prosessien hallintaa koskien voi olla tarpeen tehdä? Yhteyksiä Käyttöjärjestelmän alaisuudessa toimii myös tiedostojärjestelmä, josta on puhetta samassa yhteydessä kuin siitä, miten lähinnä käyttäjien pääsyä tiedostoihin tai sisäänpääsyä koneeseen valvotaan. Jotkin tämän jakson asiat voi olla helpompi kytkeä tietoturvaan, jos edellä mainittujen lisäksi tutustuu myös tietoturvapolitiikan ideaan. Havainnollistusta 1. Tutustu menettelyyn, jolla Windowsissa saa palautetuksi roskakoriin siirretyt tiedostot. Tyhjeneekö roskakori joskus itsekseen? 2. Katso millaisia lokitietoja unix-koneen hakemistosta /var/adm/ (tai /var/log/) löytyy. Komennolla last saat tulostetuksi wtmp-lokin. Se on tavattoman pitkä joten voit putkittaa: last | more. Voit myös katsoa mitä tietoa itsestäsi on: last | grep käyttäjätunnuksesi.

Käyttöjärjestelmään perinteisesti liittyviä turva-asioita

• Jos käyttäjiä on vain yksi (kuten toimikortissa), hänen prosessi(e)nsa erottamiseen käyttöjärjestelmän muistialueesta riittää kiinteä raja (aita, 'fence'), jonka toiselle puolelle ei sallita viittauksia. Luonnollinen toteutus käyttää suhteellisia osoitteita, jotka päivitetään ('relocation') todellisiksi vasta ohjelmaa ladattaessa.
• Useamman käyttäjän tapauksessa tarvitaan sekä ala- että yläraja ja lisäksi, koska prosesseilla on yleensä dynaamista dataa, tarvitaan rajat myös sille.
• Jos prosessien pitää voida käyttää muistia yhteisesti, tai jos tietty prosessi haluaa suojata osan viittaamastaan muistista esim. kirjoittamiselta, voidaan muistiyksiköt (sanat tai jotkin suuremmat mutta silti pienet kokonaisuudet) varustaa pääsynvalvontabiteillä. Järjestelmä kuluttaa muistia, mutta on joustava. Eduista huolimatta se ei ole yleistynyt, lähinnä yhteensopivuusperinteen takia.
• Segmentointi: ohjelma (ja data-alueet) jaetaan osiin, jotka ovat loogisia nimettyjä kokonaisuuksia ja jotka sijoitetaan muistiin yhtenäiselle alueelle. Käyttöjärjestelmä pitää yllä osoitetaulua ja kaikki muistiviittaukset tapahtuvat sen kautta, mikä mahdollistaa monenlaiset turvatarkastukset (myös usean viittaavan prosessin osalta). Toisaalta pitää vahtia varsinkin dynaamisia viittauksia segmentin ulkopuolelle. Segmentoinnin toteutuksessa on oma vaivansa ja lisäksi se aiheuttaa muistin pirstoutumista.
• Sivutus ('paging') jakaa ohjelman vakiokokoisiin palasiin, jotka sijoitetaan muistiin ja joihin viitataan segmenttien tavoin. Muisti täyttyy tarkasti ja sivurajan ylitys pysyy kätevästi kurissa osoitteen ylivuotona uudelle sivulle. Käyttöjärjestelmä huolehtii sivujen jakamisesta, mutta ei pysty vastaavalla tavalla eriyttämään niihin pääsyn valvontaa kuin segmentoinnissa.
• Sivuttamalla segmenttejä saavutetaan molempien järjestelmien etuja. Hintana on tietenkin lisävaihe viittausten toteutuksessa.

• Peräkkäin tietty kokonaisuus kerrallaan: kirjoittimet, nauhat.
• Peräkkäin keskeytysmekanismin avulla: prosessit CPU:ssa; lisäksi prosessien välinen kommunikointi ja erityisesti lukkiutumisen ('deadlock') estäminen.
• Rinnakkain: prosessien muistivaraus ja tiedostot, myös mahdollinen rinnakkaisten prosessorien hallinta.
• (Porrastetusti tai liukuhihnamaisesti: prosessorin sisäisen toteutuksen tapaan, joka ei ole käyttöjärjestelmän asia.)

Joitakin "pieniä" käytäntöjä

Yksi suosittu keino yrittää päästä käyttämään konetta luvattomin valtuuksin on suid- ja sgid-ohjelmien hyödyntäminen. Tavallinen ohjelma käynnistyy käyttäjänsä mukaisin oikeuksin. Suid-ohjelma on sellainen, että sen käynnistämällä prosessilla on ohjelmatiedoston omistajan oikeudet (eli prosessin uid, user-id, on sama kuin omistajan uid). Tällainen menettely on varsin hyödyllinen. Esimerkiksi salasanan vaihto-ohjelma pystyy suid-ohjelmana kenen tahansa ajamana kirjoittamaan /etc/passwd-tiedostoon, johon vain root-käyttäjällä on kirjoitusoikeus. Sgid on muuten vastaava kuin suid, mutta koskee ryhmää. Sekä suid että sgid ovat yksi bitti kunkin tiedoston pääsynvalvontatiedoissa ja ne näytetään x- eli suoritusoikeuden tilalla, jos ne on asetettu. Esimerkkejä näistä biteistä Lintulan kiuru-koneen hakemistossa /usr/bin/:

---s--s--x   3 root   sys    99844 Apr 21 08:11 passwd
---x--s--x   1 bin    sys    50712 Oct  6  1998 netstat
---s--x--x   1 root   bin    29292 Oct  6  1998 login

Suid- tai sgid-ohjelmat eivät ole turvallisuusongelma, kunhan mitään ohjelmaa ei tarpeettomasti eikä vahingossa määritellä sellaiseksi eikä näiden ohjelmien kautta pääse tekemään mitään muuta kuin oli tarkoitettu.

Kun tässä on puhe unix-tiedoston omistuksesta, saadaan esille toinenkin esimerkki siitä, mitä kurssin johdannossa tietoturvamekanismiksi mainittu omistusoikeus voi tarkoittaa. Vaikka muilla olisi w-oikeuden turvin mahdollisuus kirjoittaa tiedoston päälle jotain aivan muuta, vain omistajalla on oikeus muuttaa oikeuksia.

Kun ajatellaan sitä, että käyttöjärjestelmän pitäisi myös valvoa, ettei mikään prosessi (esim. pillastuttuaan) syö kohtuuttomasti aikaa tai muistia, tai ole jollain muulla tavalla asiaton, päästäänkin jo laajempaan aiheeseen, tunkeutumisen havaitsemiseen.

Tunkeutumisen havaitseminen Motivointia Yleensä ei voida täysin ehkäistä hyökkäyksiä ja väärinkäyttöä. Tunkeutumisen havaitseminen (intrusion detection) ja (lisä)vahinkojen estäminen on seuraavaksi parasta, mitä voidaan tehdä. Periaate on yksinkertainen: kerätään tietoa kaikesta oleellisesta, mitä järjestelmässä on tekeillä ja tapahtuu, tutkitaan tätä tietoa ja tehdään johtopäätöksiä, ovatko havaitut seikat oire jostainhyökkäyksestä vai ovatko ne osa kyseisen ympäristön normaalia käyttäytymistä. "IDS-ala on kypsynyt huomattavasti sitten vuoden 1998 ja nykyään se on noussut tärkeään asemaan verkkoturvallisuudessa palomuurien ja virusten torjunnan rinnalle. Toteutusten mutkikkuudesta huolimatta periaatteet ovat hyvin yksinkertaiset." (R.J.Hontañon: “Deploying an Effective Intrusion Detection System, Netw.Mag. Sep 2000. Sisältöä ja tavoitetta Käsitellään ensin lyhyesti tapahtumakirjanpitoa unixissa, sitten mainitaan rakenteen analysointivälineitä ja esitellään CERT:n käytännön ohjeita. Lopuksi esitetään tunkeutumisen havaitsemismenetelmien yleinen luokittelu. Tavoitekysymyksiä: Miten voidaan havaita, jos jokin ison tietokoneen sadoista prosesseista onkin jollain tavalla luvaton? Mitä tarkoittaa tietokoneeseen tai tietokoneverkkoon tunkeutuminen ('intrusion') ja mitä keinoja sellaisen havaitsemiseksi on? (Pääpaino on havaitsemiskeinoissa; mainitse ainakin neljä erilaista.) Unix-tiedosto lastlog sisältää kunkin käyttäjän tuoreimman sisäänkirjautumisen ajankohdan. Mitä hyötyä tästä tiedostosta on tietoturvan kannalta? Miten tällaisen tiedon perusteella voidaan havaita hyökkäys? Mitä muuta tarvitaan, jotta havaittu hyökkäys voidaan jäljittää? Missä mielessä lastlog ei ole lokitiedosto? Mitä muita kuin tapahtumatietoja käytetään lähteenä järjestelmissä, jotka pyrkivät havaitsemaan tietokoneisiin kohdistuvia hyökkäyksiä? Havaitsemismenetelmien perusjako on tietämys- ja käyttäytymispohjaisiin. Luonnehdi näitä lyhyesti.

Tunkeutumisen havaitseminen

Tunkeutumisen havaitsemisen järjestelmät käyttävät kolmenlaista tietoa analyysinsa perustana:

• pitkän aikavälin tietoa (tietämystä), joka liittyy siihen tekniikkaan, jolla tunkeutumisia on tarkoitus havaita (esim. aiempien ja muihin järjestelmiin tehtyjen hyökkäysten tietokanta).
• tiedot nykyisen järjestelmän tietynhetkisestä tilasta ja rakenteesta, eli konfiguraatiosta. Sellaisenaan tämä tieto voi paljastaa haavoittuvuuksia, eli mitä voisi tapahtua. Se voi myös antaa viitteitä siitä, mitä ehkä on tapahtunut, vaikkei itse tapausta olisikaan nähty.
• kirjanpitotietoa ('audit log') tapahtumista. Tällä voitaisiin periaatteessa saada rosvo kiinni itse teosta (tai vähän sen jälkeen).

Tapahtumat lokitiedostoihin

• wtmp: käyttäjätunnus, login-aika, pääte jolta yhteys otettiin, mahdollisen etäkoneen nimi, yhteysajan kesto, mahdollisia prosessi- ja istuntotunnisteita. Tämän tiedoston voi lukea last-ohjelmalla (esim: "last käyttäjätunnus").
• loginlog: epäonnistuneet login-yritykset;
• sulog: su-komennon käytöt ja epäonnistumiset siinä (su:lla "muunnutaan" toiseksi käyttäjäksi, oletuksena 'root' eli superuser; tämä ei ilmene wtmp:ssä);
• aculog: ulossoittavien modeemien (automatic call units) tietoja;
• (p)acct: kunkin käyttäjän ajamat komennot (luetaan lastcomm-komennolla);
• messages: konsolille tulleet viestit;
• vold.log: virheet ulkoisten tietovälineiden käytössä.

• lastlog: kunkin käyttäjän tuorein sisäänkirjautumisaika (näkyy aina seuraavan kerran alussa ja olisi hyvä jokaisen tarkastaa).
• utmp: kullakin hetkellä sisällä olevat käyttäjät ja heistä vastaavat tiedot kuin wtmp:ssä (tätä käyttävät mm. who- ja finger-ohjelmat)

Rakenteen eheys ja kestävyys

Hyökkäystyökaluilla voi tarkistaa, onko omassa järjestelmässä aukkoja.

• Salasanan murto-ohjelma(kokoelma) Crack on yksinkertainen esimerkki. Sitä kannattaa ajaa oman järjestelmän käyttäjiä "vastaan", jotta kukaan ei pääsisi käyttämään heikkoa salasanaa, jonka joku voisi murtaa ulkopuolelta.
• Tripwire on työkalu, jota käytetään, kun epäillään, että on tapahtunut tunkeutuminen. Se tarkastaa ovatko käytettävät ohjelmistot ja konfiguraatiotiedostot eheitä (muuttumattomia) vertaamalla niitä varmuuskopioihin tai niistä laskettuja tiivistefunktioita etukäteen talletettuihin arvoihin. TTKK:lla on tehty Tripwire-tyyppinen eheystarkistusohjelmisto AIDE (Advanced Intrusion Detection Environment), joka säännöllisten ilmaisujen (reg.expr.) avulla yksinkertaistaa komentojen syöttöä.
• COPS, Computer Oracle and Password System, on ohjelma, joka tarkastaa tärkeiden tiedostojen eheyden, käyttäjien konfiguraatiot ja tiedosto-oikeudet.
• Security Administrator Tool for Analyzing Networks (SATAN) on kokoelma työkaluja, joilla järjestelmää tutkitaan ulkopuolelta. Tämä on hyödyllinen ohjelma, mutta sitä lienee syytä käyttää (ja paikata sen löytämät aukot) myös siksi, ettei kukaan muu pääsisi käyttämään sitä.

Muuan käytännön ohjeisto hyökkäysten havaitsemiseen

1. lokitiedostot: epätavalliset paikat, joista on otettu yhteyttä tai epätavalliset toimet.
2. suid- ja sgid-tiedostot (esim. find-ohjelmalla)
3. varusohjelmistot (system binaries)
4. paketinnuuskijat (packet sniffers)
5. tiedostot, joita ajetaan ajastettuina cron- tai at-ohjelmilla.
6. ettei tarjolla ole valtuuttamattomia verkkoon päin tarjottavia palveluita (siis sellaisia, jotka inetd-demonin verkosta saama pyyntö käynnistäisi /etc/inetd.conf-tiedostossa olevien määritysten perusteella).
7. /etc/passwd-tiedosto
8. järjestelmän ja paikallisen verkon konfiguraatio (siis tiedostot joissa kerrotaan millä koneilla on erioikeuksia yhteyksiä muodostettaessa: /etc/hosts.equiv, /etc/hosts.lpd ja systeemitunnusten .rhosts-tiedostot).
9. kaikkialta epätavalliset tai piilotetut tiedostot
10. kaikki koneet paikallisesssa verkossa

Jonkin havaitsemismenetelmän hyvyyttä voidaan arvioida seuraavissa ulottuvuuksissa:

• tarkkuus: tavoitteena mahdollisimman vähän vääriä hälytyksiä.
• kattavuus: tavoitteena ettei mikään hyökkäys jää huomaamatta.
• ajankohtaisuus: analyysin pitää tapahtua, kun jäljet ovat vielä tuoreita ja vahinkoja on ehkä vielä mahdollista rajoittaa.
• suorituskyky: järjestelmän pitäisi olla riittävän tehokas jo ajankohtaisuusvaatimuksen takia mutta myös siksi, ettei se häiritsisi liiaksi muuta tietojenkäsittelyä.
• vikasietoisuus: järjestelmän pitäisi itse olla suojassa hyökkäyksiltä, erityisesti se ei saisi joutua tukkoon. Asiaa hankaloittaa se, että järjestelmät toimivat tavallisesti normaalien ja siis haavoittuvien käyttöjärjestelmien puitteissa.

1. Tapahtumatietojen lähde. Seuraavista kahdesta on luonnollisesti myös yhdistelmiä
   • Isäntäkoneen puitteissa: perinteinen, sittemmin mukaan eri isäntäkoneiden tietojen (joko lokien tai hälytysten) vaihto.
     • järjestelmä itse toimittaa, esim. ps- tai pstat-ohjelmilla, jotka käsittelevät suoraan käyttöjärjestelmän ytimen prosessitauluja. Tämä ei yleensä ole riittävän rakenteinen eikä siis käytännöllinen tiedonkeruutapa.
     • normaalit lokitiedostot (kuten edellä unixissa). Huolimatta tehokkuudestaan ja yleisestä saatavuudestaan ne eivät ole kovin hyviä lähteitä. Syitä tähän ovat: eivät parametrisoitavissa tarpeen mukaisesti, ajanmääritys ei riittävän tarkka, tapahtumasta jää liian vähän tietoa (esim. ei komennon argumentteja), jatkuvasti ajautuvat ohjelmat (demonit) jäävät ulkopuolelle, tieto tulee vasta kun prosessi päättyy.
     • erillisen kirjausohjelman (syslog tai vastaava) avulla tehdyt lokit: parempia ja suositumpia lähteitä, vaikka syslog-ohjelmastakin on löydetty tietoturva-aukkoja.
     • erityinen turvallisuustiedon kirjausjärjestelmä (jollainen vaaditaan oranssin kirjan C2-tasosta alkaen). Siinä otetaan huomioon kaikki sellaiset systeemikutsut, jotka kulkevat turvallisen tietojenkäsittely-ytimen (käytännössä unix-kernelin) rajan yli. Sen ulkopuolisten tapahtumien ei ajatella loukkaavan systeemin turvallisuutta ja sisäpuoliset taas ovat jo määritelmän mukaan turvallisia. Tietoja saadaan riittävän yksityiskohtaisina, mutta ei silti tarvitse kirjata aivan kaikkea. Tietojen määrä on kuitenkin huomattavan suuri ja niiden käsittely kuluttaa paljon resursseja. Järjestelmä on myös varsin monimutkainen ylläpitäjänsä kannalta.
   • Verkossa liikkuva tieto
     • verkonhallintaohjelman toimittamana (esim. SNMP, Simple Network Management Protocol): erityisesti MIB (Management Information Base)
     • itse paketeista, paketinnuuskijoilla (niiden käyttö ei ole hyökkääjien "yksinoikeus")
2. Havaitsemismenetelmä
   • Tietämyspohjainen menetelmä käyttää kertynyttä tietoa tunnetuista hyökkäyksistä ja järjestelmän omista heikkouksista. Menetelmä tulkitsee sallituksi sellaisen toiminnan, joka ei sen tietämyksen mukaan näytä hyökkäykseltä. Vääriä hälytyksiä ei siis yleensä tule, mutta kattavuus edellyttää laajaa ja toistuvaa hyökkäysten mallintamista, jossa otetaan huomioon myös yleistettävyys kulloinkin kyseessä olevaan järjestelmään.
     • asiantuntijajärjestelmät sisältävät sääntöjä, joilla hyökkäyksiä voidaan kuvata ja siten tunnistaa lokitiedoista. Lokitiedon abstraktiotasoa siis nostetaan varustamalla sen merkityksellä (semantiikalla). Voidaan myös laatia monimutkaisempia malleja alkaen hyökkääjän erilaisista tavoitteista.
     • tunnusmerkkianalyysi ('signature analysis'). Vastaavalla tavalla kerättyä tietoa kuin edellisessä sovelletaan tässä toiseen suuntaan, nimittäin alentamalla hyökkäyskuvauksen semanttista tasoa tehokkaasti lokitietojen joukosta havaittaviksi hahmoiksi. Menetelmää on sovellettu useissa tuotteissa.
     • Petri-verkot: monipuolinen keino esittää em. tunnusmerkkejä.
     • tilasiirtymäkaavioitakin voidaan käyttää hyökkäysten mallintamiseen
   • Käyttäytymispohjainen menetelmä lähtee hyökkäysten mallintamisesta toimintana, joka ei vastaa aiemmin havaittua normaalia toimintaa (ikäänkuin: "mikä ei ole sallittua on kiellettyä"). Lähestymistapa on kattava, mutta vaikeampi toteuttaa kuin tietämyspohjainen, erityisesti huonomman tarkkuuden vuoksi. Tarvitaan laajaa ja toistuvaa "normaalin" havainnointia, mutta siihen voi jo ehtiä sisältyä hyökkääjäkin.
     • tilastot: useita muuttujia, joita mitataan ajan kuluessa ja muodostetaan käyttäjien pitkän ja lyhyen aikavälin profiileja eli muuttujien jakaumia. Tämä on eniten käytetty käyttäytymispohjainen menetelmä.
     • asiantuntijajärjestelmät: käyttäytymistä mallinnetaan kerättyjen tilastojen ja politiikan perusteella muodostuvilla säännöillä.
     • neuroverkot: oppivat syöttö- ja tulosvektoreiden välisiä (epälineaarisiakin) relaatioita. Voisivat periaatteessa olla hyökkäystä edustavia toimintaketjuja, joita voitaisiin sitten käyttää vastaavien löytämiseen lokeista. Käytännössä on sovellettu vain laillisten käyttäjien käytöksen oppimiseen.
     • käyttäjän aikomusten tunnistaminen: mitä käyttäjä oikeastaan on tekemässä ja millaista yksityiskohtaista käytöstä siitä seuraa (menetelmä esiintyy vain yhdessä hankkeessa)
     • immunologia: normaali toiminta mallintuu lyhyiden systeemikutsujonojen kokoelmana. Jos havaitaan jonkin muunlaisia jonoja, tehdään hälytys
3. Reagointi, eli mitä tehdään, kun havaitaan hyökkäys.
   • passiivinen tyytyy generoimaan hälytyksen;
   • aktiivinen: katkaistaan yhteys tai muutetaan konfiguraatiota (jne.); yleistymässä passiivisen reagoinnin sijasta.

Tunkeutumisen havainnoinnissa on samanlaista virusten torjunnan kanssa tunnusmerkkien päivittäminen. Pieni muunnos voi nimittäin päästä läpi havainnointiohjelman aiemmista versioista. Vertaa luetteloa hyökkäysten muuntelusta toisen kirjoittajan kommentoidessa niitä: "50 Reasons IDS Systems Work".

Näkökulmia luotettuun käyttöjärjestelmään Motivointia Olisi epäilemättä suotuisaa, jos käyttöjärjestelmä osattaisiin rakentaa siten, että se pystyisi huolehtimaan nykyistä enemmän turvallisuudesta. Käyttöjärjestelmät ovat niin monimutkaisia, että tämä on kovin vaikea tehtävä. Toisaalta se olisi samasta syystä entistäkin tärkeämpää. Sisältöä ja tavoitetta Tavoitekysymyksiä: Millainen voisi olla tavallista turvallisemman käyttöjärjestelmän rakenne ja toimintaperiaate? Mikä merkitys asetetulla tietoturvapolitiikalla on tällaisen järjestelmän rakentamisessa? Mikä on viitemonitori ja mikä sellaisen tehtävän on turvallisessa käyttöjärjestelmässä? Yhteyksiä Tämän jakson asialla on paljon tekemistä monitasoisen turvallisuusmallinnuksen (Bell- LaPadula ym.) sekä kriteerimallien (Common Criteria ym.) kanssa. Edellistä varten tarvittavat tiedon kulun rajoitukset täytyy tietenkin toteuttaa luotettavalla käyttöjärjestelmän tasolla. Kriteerimallit puolestaan kiinnittävät paljon huomiota perusteisiin, joilla luotettavuuteen voidaan uskoa.

Näkökulmia luotettuun käyttöjärjestelmään

Lähtökohtana voidaan pitää takeita siitä, ettei itse laitteistoa ole peukaloitu. Tämä aihe on esillä erikseenkin. Nyt mielikuvana voisi olla sellainen, että "systeemi" (viitemonitori, joka on mainittu toisaallakin) välittää kaiken vuorovaikutuksen käyttäjien ja resurssien välillä - tarkistaen joka kerta luotetusta pääsynvalvonnan tietokannasta, sallitaanko vai kielletäänkö vuorovaikutus.

Tietoturvallisuuden kannalta olisi tietysti suotavaa, että koko tietojärjestelmän voisi sanoa kuuluvan luotetun tietojenkäsittelyn piiriin. Käytännössä TCB:n on kuitenkin parempi olla suppea, koska kovin suuren osuuden turvallisuudesta ei voitaisi kuitenkaan vakuuttua. Periaatteessa TCB:n ulkopuoliset osat pitäisi voida antaa vaikka hyökkääjän kirjoitettaviksi, eikä politiikasta silti tarvitsisi tinkiä.

TCB:n suhteellisesta osuudesta riippumatta turvallisuusmekanismit voidaan tietokoneen arkkitehtuurissa levittää laajalle alalle tai keskittää. "Security kernel"-menettelyssä tehdään jälkimmäisellä tavalla. Siinä arkkitehtuurin muista osista eristetty "turvaydin" huolehtii järjestelmän turvallisuuspolitiikan toteuttamisesta. Tällainen turvaydin on tyypillisesti osin kovossa ja osin käyttöjärjestelmässä ja se on asennettu sinne jo järjestelmää rakennettaessa. Suppeuden ansiosta sitä on silti mahdollista melko yksinkertaisesti mukauttaa politiikan tarkentuessa - esim. uudentyyppisten hyökkäysten tultua ilmi.

Seuraavala luettelo esittää tärkeimmät vaatimukset turvaytimelle. Ne ovat kyllä TCB:ltä toivottavia ominaisuuksia yleisemminkin.

• Eheyden säilyminen, asiattoman peukaloinnin tekeminen mahdottomaksi.
• Ohittamattomuus: politiikan mukaisia turvatoimia, joista ydin vastaa, ei saa olla mahdollista hoitaa ilman ydintä.
• Vakuuttuminen turvallisuudesta:
  • käytännön ja monipuolisen testauksen kautta, erityisesti tunnettujen hyökkäysten testauksella;
  • huolellisen ja hyvin dokumentoidun suunnittelun, rakentamisen ja ylläpidon perusteella;
  • suunnittelussa mahdollisesti sovellettujen formaaleihin menetelmiin liittyvien todistusten perusteella;
  • standardien pohjalta tehtyjen arviointien ja sertifiointien perusteella (esim. Common Criteria, jota käsitellään toisaalla);
• Laitteistoratkaisujen käyttö parantamaan tehokkuutta ja luotettavuutta esim. muistin ja suoritusympäristön eriyttämisessä, mahdollisesti myös I/O-toiminnoissa;
• Tarpeettoman monimutkaisuuden välttäminen (erityisen hankalaa jos ydintä yritetään saada aikaan jälkiasennuksena)
• Vikasietoisuus: häiriöidenkin sattuessa pitäisi politiikasta pystyä huolehtimaan.

• laitteisto;
• jonkinlainen prosessinvalvontamekanismi, jolla turvallisuudelle tärkeät prosessit pystytään erottelemaan muista;
• perustavaa laatua olevat tiedostot, erityisesti pääsynvalvontaan ja autentikointiin liittyvät;
• suojattu muistialue, jotta viitemonitoria ei päästä peukaloimaan;
• jonkinlainen kommunikointimekanismi TCB:n eri prosessien välisiin tarpeisiin, esimerkiksi viitemonitorilta kirjausjärjestelmälle.

TCB:n rakentamisessa voidaan noudattaa samanlaista "sipuli"-rakennetta kuin käyttöjärjestelmässä yleensäkin. Vastaavasti kuin tietoliikenneprotokollien kerrosrakenteessa TCB:n ylemmät kerrokset saavat palvelua alemmilta kerroksilta ja mitä alempana ollaan sen parempaa luotettavuutta voidaan käytännössäkin edellyttää.

Esimerkki luotettavasta järjestelmästä on KeySAFE, jonka tarkoitus on täyttää oranssin kirjan B-tason vaatimukset, KeyKOS-käyttöjärjestelmän yhteydessä - jolla puolestaan on seuraaja: EROS: The Extremely Reliable Operating System (vuodelta 1999). Tässä KJ-perheessä on täysin toisenlaisiin ratkaisuihin johtanut lähestymistapa kuin Unixissa, sivupohjaisuus segmentoinnin sijasta ja prosessien pysyvyys (kaatumisenkin yli). Tässä on kyseessä kykyperustainen pääsynvalvonta.