NO965546L - Fremgangsmåte for å sikre samvirke mellom objekter i et objektorientert program - Google Patents

Description

Foreliggende oppfinnelse gjelder det å gjøre objektorienterte programmer sikre.

Nærmere bestemt gjelder oppfinnelsen en fremgangsmåte for å sikre samvirket mellom en databehandlingsprosedyre for et kundeobjekt og en annen databehandlingsprosedyre for et tjenerobjekt.

Samvirket mellom en databehandlingsprosedyre for et kundeobjekt og en databehandlingsprosedyre for et tjenerobjekt stammer fra en tjenesteordre fra kundeobjektet til tjenesteobjektet. Denne tjenesteordre implementeres vanligvis ved å anrope databehandlingsprosedyren for tjenerobjektet i kildekoden for databehandlingsprosedyren for kundeobjektet.

Under utførelsen av et objektorientert program som ikke er blitt gjort sikkert, skapes objekter som reaksjon på momentvalgordre og tilgangen til dataene for et objekt (tjenerobjekt) ved hjelp av et annet objekt (kundeobjekt) er gjort mulig ved hjelp av et samvirke mellom de to behandlingsprosedyrer for henholdsvis kundeobjektet og tjenerobjektet. Det følger at denne type ukontrollert samvirke kan vise seg å være farlig med hensyn til konfidensialiteten og integriteten av følsomme data i programmet.

Formålet for oppfinnelsen er å foreslå en løsning på problemet ved å styre tilgangen.

Dette er oppnådd ved hjelp av en fremgangsmåte for i et objektorientert program å sikre samvirket mellom en databehandlingsprosedyre for et kundeobjekt og en annen databehandlingsprosedyre for et tjenerobjekt i nevnte program, idet fremgangsmåten omfatter trinn hvor:

- et autorisasjonsnivå tilordnes kundeobjektet,

- et "dynamisk" følsomhetsnivå tilordnes databehandlingsprosedyren for tjenerobjektet når tjenerobjektet er momentvalgt av en objektkonstruktør, idet nevnte dynamiske følsomhetsnivå beregnes på grunnlag av statiske følsomhetsnivåer og et autorisasjonsnivå meddelt objektkonstruktøren, hvor de statiske følsomhetsnivåer inneholdes i en hukommelse og hvert nivå er tilordnet forskjellige logiske entiteter i programmet, - autorisasjonsnivået tilordnet kundeobjektet bringes til å bli meddelt databehandlingsprosedyren for tjenerobjektet via en melding sendt av databehandlingsprosedyren for kundeobjektet, for å anrope databehandlingsprosedyren for nevnte tjenerobjekt, og - det kontrolleres i databehandlingsprosedyren for tjenerobjektet om autorisasjonsnivået som er blitt meddelt denne er tilstrekkelig sammenlignet med det dynamiske følsomhets-nivå som er blitt tilordnet denne.

Således kan kundeobjektets tilgang til tjenerobjektets data bli kontrollert eller til og med forbys. Mekanismene for å utføre sådan kontroll kan implementeres i kildekoden for et program som skal gjøres sikkert, på en måte som er forholdsvis uavhengig av det parti av koden som angår anvendelsen av programmet. Det er således mulig å implementere dem ved automatisk behandling av filen eller filene som inneholder kildekoden for det program som skal gjøres sikkert.

En sådan metode faller innenfor en objektorientert sikkerhetsmodul med flere nivåer og med sikre data som har et "granularitetsnivå" som ikke bare når objektklasser og objekter, men også klasseattributter og databehandlingsprosedyrer for vedkommende objekter (idet nevnte prosedyrer tilsvarer klassemetoder i bred betydning innen objektorientert programmering).

Særtrekkene og fordelene ved oppfinnelsen vil fremgå klarere ut fra den etterfølgende beskrivelse av et utførelseseksempel og ut fra de vedføyde tegninger, på hvilke: Fig. 1 meget skjematisk viser de forskjellige trinn forut for implementering av sikker hetsmekanismer i kildekoden for et objektorientert program som skal sikres, Fig. 2 viser prosessen hvor et dynamisk sikkerhetsnivå tilordnes en databehandlings prosedyre for et valgt objekt, og Fig. 3 viser prosessen hvor et autorisasjonsnivå kontrolleres i forhold til et dynamisk følsomhetsnivå under utførelsen av en databehandlingsprosedyre for et tjenerobjekt.

Den "sikkerhet" som det sikrede program gir, er definert ved en formell sikkerhetsmodell basert på flernivå-sikkerhetspolicyen ifølge Bell & Lapadula beskrevet i artikkelen "Secure computer; unified exposition and multics interpretation", Technical Report ESD-TR-75-306, The Mitre Corporation, Bedford MA, mars 1976.

Den foreslåtte flernivåmodell for sikkerhet er kjennetegnet ved de etterfølgende egenskaper: (1) dersom en funksjon eller en databehandlingsprosedyre fl for et objekt 01 forsøker å anrope en funksjon f2 for et objekt 02, må det autoriasjonsnivå som f1 besitter

råde over følsomhetsnivået beregnet for f2,

(2) dersom en funksjon f1 for et objekt 01 forsøker å ødelegge et objekt 02, må autorisasjonsnivået som fl besitter råde over følsomhetsnivået som 02 innehar, (3) en funksjon f2 for et tjenerobjekt 02 mottar autorisasjonsnivået fra funksjonen f1 for kundeobjektet 01 som den anroper, (4) dersom en funksjon f velger et objekt O av en klasse C som har en attributt A samt en funksjon M, da er: (4.1) følsomhetsnivået for objekt O lik det største følsomhetsnivå tilordnet klassen C

og autoriasjonsnivået som funksjonen f besitter,

(4.2) følsomhetsnivået for attributten A for objektet 0 lik det største følsomhetsnivå

tilordnet attributten A i klassen C og autorisasjonsnivået som funksjonen f besitter, og

(4.3) følsomhetsnivået for funksjonen M for objektet O lik det største følsomhetsnivå

tilordnet funksjonen M i klassen C og autorisasjonsnivået som funksjon f

besitter,

(5) følsomhetsnivået for en momentvalgt klasse råder over det tilordnet sin para-metrerbare klasse,

(6) følsomhetsnivået for en underklasse råder over det tilordnet en overklasse,

(7) følsomhetsnivået for en inneholdt klasse råder over det tilordnet den inneholdende klasse,

(8) følsomhetsnivået for en attributt i en klasse råder over det tilordnet klassen, og

(9) dersom en attributt A i en klasse C1 har en klasse C2 som sin verdi, bestemmes følsomhetsnivået for C2 av følsomhetsnivået tilordnet A.

I fig. 1 er kildekoden for det objektorienterte program som skal gjøres sikkert, betegnet P og dette inneholder vanligvis ett eller flere klassehierarkier. Hver klassedeklarasjon inneholder en forklaring av attributter og funksjoner slik det er velkjent i objektorientert programmering.

I sikkerhetsmodellen angitt ovenfor gjelder egenskapene (5) til (9), kjent som "statiske" egenskaper, bare klasser, klasseattributter og klassefunksjoner. Derimot gjelder egenskapene (1) til (4) som betegnes "dynamiske" egenskaper, objekter (momentvalg av klasser) og deres funksjoner.

Koden i kildeprogrammet P behandles i et analysetrinn 10 (som valgfritt utføres automatisk ved hjelp av en syntaksanalysator) for å identifisere de forskjellige logiske entiteter i programmet, dvs dets klasser, klasseattributter og klassefunksjoner. Ved enden av trinnet 10 er det skapt en databasestruktur 15. Denne database er ment å inneholde såkalte "statiske" følsomhetsnivåer tilordnet de forskjellige logiske entiteter, og som er blitt deklarert i programkildekoden. I databasen 15 er nærmere bestemt identifikatorene for de logiske entiteter (navn på klasser, attributter, osv ) opplistet i poster som følgelig vil motta de statiske følsomhetsnivåer.

I løpet av trinnet 20 tilordnes deretter statiske følsomhetsnivåer til de deklarerte klasser og klasseattributter i programmet. Disse statiske følsomhetsnivåer skrives med andre ord inn i databasen i samsvar med identifikatorene for de tilhørende logiske entiteter. I løpet av trinnet 20 er det nødvendig i et trinn 30 å kontrollere at følsomhetsnivåene tilordnet de logiske entiteter faktisk tilfredsstiller de statiske egenskaper ifølge sikkerhetsmodellen angitt ovenfor. Dette trinn utføres vanligvis ved hjelp av en data-administrator som har tillatelse til å gjøre programmet sikkert. Ved negativt resultat gjentas trinnet 20.

Ved positivt resultat beregnes de statiske følsomhetsnivåer for klassefunksjonene så ved 40 og skrives inn i databasen 15. Det å beregne følsomhetsnivåene for funksjonene fordrer kjennskap til følsomhetsnivåene for attributtene som brukes av rene lesefunk-sjoner samt følsomhetsnivåene for dem som brukes av lese/skrivefunksjoner. De statiske følsomhetsnivåer kan også beregnes under utførelsen av programmet.

Ved enden av trinnet 40 er databasen 15 fullstendig lastet med statiske følsomhets-nivåer. De sikkerhetsmekanismer som er spesifikke for å ta i bruk de dynamiske egenskaper ved sikkerhetsmodellen, må så implementeres i kildekoden for det objektorienterte program som skal gjøres sikkert. Programkoden som inneholder disse sikkerhetsmekanismer kompileres så for å oppnå et sikret, utførtbart program betegnet PS. Når det utføres benyttes de statiske følsomhetsnivåer av sikkerhetsmekanismene for å beregne dynamiske følsomhetsnivåer, slik som beskrevet nedenfor. De statiske følsomhetsnivåer kan leses ut fra databasen 15 under utførelsen av programmet, men dette kan straffe seg sett ut fra tiden for utførelsen. Det foretrekkes å laste alle de statiske følsomhetsnivåer inn i en intern datastruktur i det sikrede program når det startes.

Det skal bemerkes at disse sikkerhetsmekanismer kan implementeres under utviklingen av programkildekoden, og i så fall bygges databasen 15 ved slutten av utviklingen av programkildekoden. Disse sikkerhetsmekanismer kan også implementeres i kildekode som allerede foreligger for et program, og i så fall innebærer implementeringen modifisering av kildekoden, idet sådan modifisering da kan utføres ved hjelp av automatisk prosessering.

Det følger nå en beskrivelse av et eksempel på sikkerhetsmekanismer implementert i kildekoden for et objektorientert program utviklet ved bruk av språket C++, idet mekanismene implementeres ved å modifisere eksisterende kildekode.

Innledningsvis gjelder modifiseringen hoveddelene av klassefunksjonene (innbefattet objektkonstruktører og -destruktører) som inneholdes i programmets kildekode. For hver funksjon legges en parameter som representerer et autorisasjonsnivå, til funksjonens parameterliste. Under utførelsen benyttes autorisasjonsnivået som et symbol som formidles fra et kundeobjekt til et tjenerobjekt, idet tjenerobjektet som mottar autorisasjonsnivået som en parameter for en av sine egne funksjoner, innbefattet konstruktøren, sender det videre som et kundeobjekt til et annet tjenerobjekt når det anroper en funksjon i nevnte andre tjenerobjekt. I hver funksjons hoveddel legges dessuten til en kontroll for å sammenligne autorisasjonsnivået med et følsomhetsnivå som dynamisk tilordnes i det øyeblikk programmet utføres.

De øvrige sikkerhetsmekanismer er sentralisert i en "overklasse" som direkte eller indirekte stammer fra alle klasser deklarert i programmets kildekode. Det er i denne overklasse at en objektkonstruktør defineres, som dynamisk tilordner et følsomhetsnivå til hver funksjon i et objekt under momentvalget av dette. Dette dynamiske følsomhets-nivå beregnes på grunnlag av både et autorisasjonsnivå meddelt som en parameter til konstruktøren av konstruktørens kundeobjekt samt statiske følsomhetsnivåer tilordnet den tilhørende klasse for objektet og for funksjonene i denne klasse. De dynamiske følsomhetsnivåer som er tilordnet objektet og hver av dets funksjoner beregnes ved anvendelse av definisjonen av egenskap (4) ifølge sikkerhetsmodellen. Det er også innenfor denne overklasse at en tilleggsstruktur for arkivering av dynamiske følsom-hetsnivåer defineres og administreres. Det er også i denne overklasse at en funksjon defineres som er egnet for å gjenvinne det dynamiske følsomhetsnivå for hver objektfunksjon som skal gjenvinnes fra arkiveringstilleggsstrukturen under anropet av objekt-funksjonen.

Appendiks 1 .A viser kortfattet kildekoden for et objektorientert program i språket C++, som skal gjøres sikkert. Den inneholder en klasse CX og en funksjon MX av typen "Type" med parametre a av typen "T1", b_ av typen "T2", c av typen "T3", osv.

Appendiks 1.B viser kortfattet kildekoden for det objektorienterte program vist i Appendiks 1.A etter modifisering. På linje 3 i Appendiks 1.B er klassen CX blitt til en underklasse av en klasse SecurityObject. ved direkte "nedarving" (i dette eksempel) eller ved indirekte "nedarving". I linje 6 er en peker til et spesialobjekt i denne klasse blitt lagt til klassen CX for innenfor dette spesialobjekt å opprettholde de statiske følsomhets-nivåer for klassen, dets attributter og dets funksjoner. I linjene 8 og 24 er autorisa-sjonsparameteren Auth av typen SecurityLeveL lagt til alle funksjonsgrensesnittene, innbefattet objektdestruktørene og -konstruktørene. I linje 26 er en betingelsessetning lagt til begynnelsen av hver funksjons hoveddel. I linjene 27 - 33 inneholder hoveddelen av hver funksjon et parti som er utførbart i det tilfelle autorisasjonsnivået Auth er tilstrekkelig sammenlignet med det (dynamiske) følsomhetsnivå Sens for metoden, og et annet parti som kan utføres i det motsatte tilfelle. I linje 15 er det bare en konstruktør som har et grensesnitt som innbefatter autorisasjonsnivået. Denne konstruksjon brukes av sikkerhetsmekanismen for å skape "ClassObjecf-objekter og den må ikke anropes av klassefunksjonene. I linjene 10 og 11 er bruken av standardkonstruktøren gjort uvirksom. Alle anrop til konstruktører må innbefatte et autorisasjonsnivå Auth (og det samme gjelder for enhver funksjon). I linje 12 er bruken av standarddestruktøren gjort uvirksom. Standarddestruktøren "delete" er erstattet med funksjonen "Destroy_". I linjene 19 og 20 er det i tillegg til å legge til et autorisasjonsnivå Auth i en konstruktørs grensesnitt, også nødvendig å legge til en peker til dens overklasse (i foreliggende tilfelle, SecurityObject.). Det skal bemerkes at med denne realisering er tilgangskontroll-klausulen forholdsvis uavhengig av funksjonskoden for bruken av programmet slik at de ovenfor beskrevne modifikasjoner lett kan utføres automatisk ved hjelp av et leksikalt analysesystem.

Appendiks 2 viser inneholdet i en fil som inneholder kildekoden for klassen SecurityObject.. I linje 3 må klassen SecurityObject. være "nedarvet" direkte eller indirekte av alle klassene som skal gjøres sikre. I linje 6 er<*>SecurityObject_ klasse-objektet for selve klassen SecurityObject. I linjene 19 og 20 går funksjonen Max. tilbake til det laveste sikkerhetsnivå (SL) som er større enn de to verdier som er meddelt som parametre. I dette eksempel er sikkerhetsnivåene implementert i form av en betegnelse SL, dvs ved hjelp av en nøyaktig oppstilling. Verdien Max_ er derfor ganske enkelt det numeriske maksimum for de to parametre. Ikke desto mindre kan også en delvis oppstilling være mulig, og i så fall kan den returnerte verdi være forskjellig fra parametrene. I den hensikt å styre skapelsen av objekter er konstruktørgrensesnittet modifisert i linje 28. På samme måte som en vilkårlig sikkerhetsklasse C utgjør en underklasse av klassen SecurityObject., vender utførelsen av en konstrukør for C tilbake til utførelsen av konstruktøren for SecurityObject. som i sin tur anroper funksjonen Instantiate.. Dette er den metode som dynamisk beregner og lagrer i hukommelse følsomhetsnivået for et objekt samt for dets funksjoner og attributter. På side 2 av Appendiks 2, linje 12, brukes funksjonen Destroy. for å styre destrueringen av et objekt. På linjene 16 og 20 på den samme side returnerer funksjonen Sens. følsomhetsnivået for et objekt eller for en funksjon.

I Appendiks 3, linje 3, velges sikkerhetsnivåene fra en samling i streng rekkefølge. I linje 4 er SL-typen innkapslet i klassen SecurityLevel.. Linjene 10 og 11 viser definisjonene av operatorene = og >= i SL-samlingen.

Appendiks 4 viser innholdet i en annen kildefil som inneholder en funksjon Secure_() som for en klasseidentifikator meddelt som en parameter, gjenvinner dens statiske følsomhetsnivå og skaper et objekt av typen Sensitivities. som inneholder følsomhets-nivået for klassen og følsomhetsnivåene for klassefunksjonene. Denne funksjon returnerer et objekt i klassen Sensitivities. definert i filen vist i Appendiks 7 og som tjener som en inngangsparameter for objektkonstruktøren.

Appendiks 5 viser innholdet i en kildekode som inneholder en funksjon CreateClassObject.O som tjener til å skape klasseobjekter i hvilke de statiske følsomhetsnivåer som gjenvinnes fra databasen 15, er lagret.

Appendiks 6 viser innholdet i en kildefil som inneholder en klasse MethodSecurity. som tjener til å ta vare på følsomhetsnivået for en objektfunksjon. Denne klasse bestemmer faktisk et objekt som er et element i en liste som inneholder de dynamiske følsomhets-nivåer for alle funksjonene i et objekt.

Appendiks 7 viser innholdet i en kildefil som inneholder klassen Sensitivities. som definerer et objekt som inneholder alle følsomhetsnivåer for et programobjekt, dvs følsomhetsnivået for selve objektet og det første objekt i en liste over objekter av typen SecurityMethod_.

Fig. 2 er en i høy grad skjematisk anskueliggjørelse av fremgangsmåten hvor et dynamisk følsomhetsnivå DSL tilordnes en prosedyre for å behandle et vilkårlig objekt mens fig. 3 er en i høy grad skjematisk anskueliggjørelse av kontrollprosessen som finner sted under samvirket mellom to databehandlingsprosedyrer, for henholdsvis et kundeobjekt og et tjenerobjekt, under anvendelse av realiseringen angitt i Appendiks 1.B-7.

I fig. 2 aktiveres klasseobjektkonstruktøren betegnet 50. Den mottar et autorisasjonsnivå AUTH fra et kundeobjekt, idet dette autoriasjonsnivå ble tilordnet kundeobjektet f.eks. etter en tilgangsanmodning via en autentiseringsprosess. Konstruktøren 50 aktiverer funksjonen Instantiate. betegnet 51, som for hver databehandlingsprosedyre for det momentvalgte objekt dynamisk beregner et dynamisk følsomhetsnivå DSL på grunnlag av autorisasjonsnivået AUTH samt de statiske følsomhetsnivåer SSL tidligere tilordnet databehandlingsprosedyrene for dette objekts klasse. Det eller de dynamiske følsom-hetsnivåer) DSL som beregnes for denne eller disse databehandlingsprosedyrer for dette objekt, lagres i en hukommelse og i det foreliggende tilfelle i objektene av klassen Sensitivities..

I fig. 3 anroper en databehandlingsprosedyre 53 for et kundeobjekt betegnet ProcObjCI en annen databehandlingsprosedyre 54 for et tjenerobjekt. Denne prosedyre er betegnet ProcObjSv. Autorisasjonsnivået AUTH for kundeobjektet meddeles ved hjelp av parametrene i anropsmeldingen til prosedyren ProcObjSv 54. I prosedyren ProcObjSv gjenvinnes det dynamiske følsomhetsområde DSL beregnet for nevnte prosedyre (ved hjelp av funksjonen SensJ og sammenlignes ved 55 med autorisasjonsnivået AUTH. Dersom autorisasjonsnivået er tilstrekkelig sammenlignet med følsomhetsnivået, utføres den første prosessering T1 betegnet 56 og denne tilsvarer derfor at tilgang tillates. Prosesseringen T1 tilsvarer med andre ord en normal prosessering implementert ved hjelp av databehandlingsprosedyren ProcObjSv. I det motsatte tilfelle utføres en annen prosessering T2 ved henvisningstallet 57 og dette tilsvarer derfor at tilgang sperres.

Claims (1)

1. Fremgangsmåte for i et objektorientert program (P) å sikre samvirke mellom en databehandlingsprosedyre for et kundeobjekt (ProcObjCI) og en annen databehandlingsprosedyre for et tjenerobjekt (ProcObjSv) i nevnte program,

   karakterisert ved at den omfatter trinn hvor:

   - et autorisasjonsnivå (AUTH) tilordnes kundeobjektet,

   - et "dynamisk" følsomhetsnivå (DSL) tilordnes (50, 51) databehandlingsprosedyren for tjenerobjektet når nevnte tjenerobjektet er momentvalgt av en objektkonstruktør, idet nevnte dynamiske følsomhetsnivå beregnes på grunnlag av statiske følsomhetsnivåer (SSL) og et autorisasjonsnivå meddelt objektkonstruktøren, hvor de statiske følsomhetsnivåer inneholdes i en hukommelse og tilordnes hver sin forskjellige logiske entitet i programmet,

   - autorisasjonsnivået (AUTH) tilordnet kundeobjektet bringes til å bli meddelt databehandlingsprosedyren for tjenerobjektet via en melding sendt av databehandlingsprosedyren for kundeobjektet, for å anrope databehandlingsprosedyren for nevnte tjenerobjekt, og

   - det kontrolleres (55) i databehandlingsprosedyren for tjenerobjektet om autorisasjonsnivået som er blitt meddelt denne er tilstrekkelig sammenlignet med det dynamiske følsomhetsnivå som er blitt tilordnet denne.