6. viikko, ma 4.10.1999

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

Muisti

• 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 viittamastaan 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-ohjelman pystyy suid-ohjelmana kenen tahansa ajamana kirjoittaa /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 osa yksi bitti kunkin tiedoston pääsynvalvontatiedoissa ja ne näytetään x- eli suoritusoikeuden tilalla, jos ne on asetettu. 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 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, tullaan oikeastaan seuraavaan aiheeseen:

Tunkeutumisen havaitseminen

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: ulossoittavavien 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ä.

• lastlogin: 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 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

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 palveluita
7. /etc/passwd-tiedosto
8. järjestelmän ja paikallisen verkon konfiguraatio
9. kaikkialta epätavalliset tai piilotetut tiedostot
10. kaikki koneet paikallisesssa verkossa

Tunkeutumisen havaitsemismenetelmien luokittelua

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 (näistä vähän tarkemmin muiden verkkoasioiden yhteydessä ensi kerralla)
     • 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 havaittaviin 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ä hyökkääjäkin mukaan.
     • 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.

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

Lähtökohtana voidaan pitää takeita siitä, ettei itse laitteistoa ole peukaloitu. Tämä aihe oli esillä viimeksi. Nyt mielikuvana voisi olla sellainen, että "systeemi" (viitemonitori) 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.

Turvaytimen tärkeimmät ominaisuudet, jotka ovat kyllä TCB:ltä toivottavia ominaisuuksia yleisemminkin:

• Eheyden säilyminen, asiattoman peukaloinnin tekeminen mahdottomaksi
• Ohittamattomuus: politiikan mukaisia turvatoimia, joista ydin vastaa, niitä 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, johon palataan myöhemmin);
• 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 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ää.