sarja 4 45318d, 45356d NDU:n yhdistäminen BLP:hen ja Bibaan ==================================== Palvelun estolla tarkoitetaan tilannetta, jossa palvelun tarvitsija ei saa palvelua ennalta sovitussa ajassa. Palvelun estoa voi esiintyä tahattomasti (kun esimerkiksi palvelin on ylikuormitettu), tai se voidaan aiheuttaa tahallaan aikomuksena aiheuttaa haittaa palvelun tarvitsijalle. Tällöin puhutaan palvelunestohyökkäyksestä (Denial Of Service, eli DOS). Palvelunestohyökkäykset voidaan välttää muunmuassa NDU-säännön avulla (No Deny Up). No Deny Up -sääntö tarkoittaa sitä, että alemmalla tasolla oleva subjekti ei saa estää palvelua ylemmällä tasolla olevalta subjektilta. Tästä seuraa, että ylimmän tason subjektit saavat palvelun aina kun sitä pyytävät, ja alempien tasojen subjektit voivat joutua odottamaan. Alimman tason subjektit saavat palvelun jos se sattuu olemaan käytettävissä, muutoin ne joutuvat odottamaan. Käytännössä NDU -sääntö sallii palvelun eston kaikilta muilta paitsi ylimmän tason subjekteilta. Seuraavassa tarkastelemme, miten NDU-sääntö voidaan yhdistää BLP- (Bell-LaPadula) ja Biba -malleissa esitettyihin turvasääntöihin. NDU:n yhdistäminen Biba-mallin turvasääntöihin ---------------------------------------------- Biba-mallissa objektit ja subjektit sijoittuvat eri tasoille eheystason mukaan. Biba kieltää subjekteja lukemasta alemman tason objekteja, ja kirjoittamasta ylemmän tason objekteihin eheyden säilyttämiseksi. Jos tähän halutaan lisätä DOS-hyökkäysten estämiseksi NDU-sääntö, ainoa mahdollinen tilanne, jossa alemman tason subjekti S1 voisi häiritä ylemmän tason subjektia S2 on se, että S1 lukee objektia O, ja S2 kirjoittaa samaan objektiin. Allaoleva kuva selventänee tilannetta. S2 \ write --------\----------------- objekti -------/------------------ / read S1 Tämä ei koske resursseja, joita ei voi "piilottaa" objektien taakse, kuten keskusmuisti tai prosessoriaika. Turvatasoille pätee seuraava: taso(S1) <= taso(O) <= taso(S2) Jos S1 ja S2 ovat samalla tasolla, ei NDU-sääntö päde, joten oletetaan, että enintään toinen yhtäsuuruus on tosi. Koska S1 on alemmalla tasolla kuin S2, ei S1:n lukuoperaatio O:sta saa häiritä S2:n kirjoitusoperaatiota O:hon. Käyttöjärjestelmältä siis edellytetään, että tarvittaessa korkeamman tason subjekti voi kirjoittaa objektiin, vaikka alemman tason subjektilla olisi saman objektin lukeminen vielä kesken. Tämä voidaan hoitaa monella tavalla. Esimerkiksi voitaisiin tehdä niin, että lukuoperaatio toimii ikään kuin tiedostoa ei olisi muutettu kesken kaiken, ja vasta uudet lukuoperaatiot näkevät muutokset. Tämä on eräänlainen tranquility-ominaisuus. Lisää tranquility-ominaisuuksia tarvitaan, jos halutaan että objektien turvamerkintöjä pystytään muuttamaan, jotta voitaisiin välttää "System Z", jossa kaikkia DOS-hyökkäyksiä ei voidakaan estää. Käytännön järjestelmässä useimmat tiedostojen käsittelyoperaatiot eivät ole atomisia, ja turvamerkintöjen muuttaminen kesken operaatiojonon saattaa aiheuttaa ei-toivottuja efektejä. Strong tranquility, eli objektien turvamerkintöjen muuttamisen kieltäminen estää nämä ongelmat, mutta toisaalta aiheuttaa muita ongelmia. NDU:n yhdistäminen Bell-LaPadula -mallin turvallisuussääntöihin --------------------------------------------------------------- Toisin kuin Biba-mallissa, BLP:ssä subjektit ja objektit sijoitetaan tasoille luottamuksellisuuden mukaan. BLP kieltää subjekteja lukemasta ylemmän tason objekteja, ja kirjoittamasta alemman tason objekteihin luottamuksellisuuden säilyttämiseksi. BLP on siis samanlainen kuin Biba, mutta tarkoituksena on suojata luottamuksellisuus ja niinpä säännöt ovat päinvastoin kuin Bibassa. Samaan tapaan kuin Bibaa tarkastellessa, ainoa tilanne, jossa alemman tason subjekti S1 voisi häiritä ylemmän tason subjektia S2 on se, että S1 kirjoittaa O:hon ja S2 lukee siitä (kuva). S2 \ read --------\----------------- objekti -------/------------------ / write S1 Käyttöjärjestelmältä edellytetään siis, päinvastoin kuin Biban tapauksessa, että tarvittaessa korkean tason subjekti voi lukea objektia, vaikka alemman tason subjektilla olisi samaan objektiin kirjoitus vielä kesken. Esimerkiksi samanlainen järjestely kuin Biban tapauksessa toimisi. Myös vastaavat tranquility-asiat pätevät tässä. Pohdintaa saatavuuden suhteesta luottamuksellisuuteen ja eheyteen ----------------------------------------------------------------- Intuitiivisesti ajatellen luottamuksellisuus, eheys ja saatavuus ovat kaikki ortogonaalisia ominaisuuksia, ts. eivät vaikuta toisiinsa. Tällöin olisi mahdollista rakentaa järjestelmä, jossa taso merkitään kolmikolla (luottamuksellisuus, eheys, saatavuus). Useat käytännön DOS-hyökkäykset tulevat verkosta käsin, ja käyttävät hyväkseen järjestelmän suunnitteluvirhettä tai bugia. Tällöin järjestelmä usein kaatuu tai jumittuu. Myös esimerkiksi verkon pullonkauloja voidaan tukkia erilaisilla floodaustekniikoilla. Näitä ongelmia ei voida ratkaista turvamalleilla. NDU-sääntö on myös varsin ylimalkainen sen suhteen, miten se oikeasti toteutetaan. Joskus palvelua ei ole mahdollista antaa kaikille haluaville, jos kapasiteetti ei yksinkertaisesti riitä. Myös massiiviset turvallisuustoimet, kuten tolkuttoman pitkät RSA-avaimilla autentikoinnit, logien kirjoittamiset yms. voivan joskus aiheuttaa palvelun eston. Lisäksi jossain tapauksissa saatetaan virhetilanteen sattuessa joutua miettimään sitä voidaanko järjestelmää enää pitää virheen jälkeen päällä vai tulisiko se sulkea. Jos järjestelmä päätetään sulkea virhetilanteen sattuessa puhutaan FailSafe -säännöstä, joka siis takaa järjestelmän eheyden ja luottamuksellisuuden, mutta poistaa virhetilanteen jälkeen saatavuuden. Jos taas käytetään FailOpen -sääntöä saadaan virhetilanteen jälkeen säilytettyä saatavuus, mutta saatetaan menettää järjestelmän luottamuksellisuus tai eheys. Järjestelmiä suunniteltaessa onkin mietittävä tarkkaan mitkä turvallisuusseikoista ovat sille tärkeimpiä eri tilanteissa: saatavuus, luottamuksellisuus vai eheys. Joskus on mahdollista toteuttaa järjestelmä, jossa nämä kaikki vaatimukset voidaan täyttää, mutta usein käy niin että jostakin niistä joudutaan tinkimään muiden kustannuksella. Käytännössä usein siis huomataan etteivät saatavuus, luottamuksellisuus ja eheys olekaan ortogonaalisia.