* 6 *

Tilgangskontroll

Ukens faktum

En algebra er et matematisk system som består av operasjoner som oppfyller spesielle regler. Dersom rekkefølgen på to operasjoner A og B har noe å si, sies algebraen å være ikke-kommutativ
  AB (objekt) == BA (objekt) ????
For eksempel, anta at A og B er tilgangskontrollmatriser som virker på en vektor med rettigheter:
 A = ( 0 0 )   B = ( 1 0 )    v = ( a )
     ( 1 0 )       ( 0 0 )        ( b )

  AB v = a
  BA v = 0
Ikke-kommutative operasjoner kan også være en modell for tilgangskontroll, der vi krever at tilgangslegitimasjon må forekomme i en viss rekkefølge.

Kapitler 3,6,7 Gollmann
Du stopper ved ekspedisjonsdisken og får ditt identitetskort. Du må vise dette kortet hver gang du skal inn i et rom, for å komme forbi vakten.

Du er et virus som prøver å komme inn i en kropp. Du har forfalsket din identitet ved å plukke opp en kode som du fant på en død celle. Nå prøver du nervøst å komme forbi sikkerhetskontrollene på celleveggene. Men selv om du kommer inn, merker nok vaktpatruljene at du er der når du sprenger cellen!

Du er et datavirus eller en computercracker. Du har stjålet ID-kortet til en annen bruker. Nå har du tilgang til alle de stedene som han/hun hadde adgang til. I tillegg finnes det ingen sikkerhets patruljer! Neste dag går du rett inn i Micro-tosh bygningen. Det finnes ikke engang en ekspedisjonsdisk for besøkere. Du trenger ikke pass! Gå og forsyn deg med alt du vil!

Etter at vi har identifisert oss for et datasystem, og den identiteten er bekreftet/autentisert, igjenstår det å bestemme hvilke privilegier vi skal ha til filer og prosesser på systemet.

Privilegiehierarkiet

Ethvert datasystem må ha minst en bruker som har tilgang til hver eneste del av systemet. Systemadministratoren trenger slike privilegier for å kunne styre og vedlikeholde systemet på vegne av andre brukere. Dette betyr at system administratoren må ha sikkerhetsklarering til hele systemet. Privilegiene som er innvilget andre bør være mindre enn dette. Jo mindre privilegier brukere har, jo mindre skade blir det av deres handlinger---jo mindre sjanse er det for sikkerhetsbrudd.
OSPrivilegert konto
Unixroot
NT/WindowsAdministrator

Reference monitor

Den grunnleggende modellen for å begrense privilegier er å se på systemressurser som objekter med visse attributter. Brukeren (the subject) prøver å aksessere objektene med en viss legitimasjon (credentials) basert på deres identitet. En aksessmonitor (reference monitor) står mellom brukere og objekter. Den sjekker rettighetene til brukerne og tillater/nekter tilgang deretter.
          Bruker   --->  Tilgangs  ----->  Aksessmonitor ----->  Objekt
                        forespørsel                
Aksessmonitoren sjekker objektets attributter, og dette kan fortell to ting: Dette var et av våre designprinsipper. Vanligvis anser vi den første av disse som et spesialtilfelle av den andre, f.eks. ved å gi rettigheter slik at ingen kan bruke et objekt på den spesifiserte måten. For eksempel, begrenser Unix execute-flagget brukeres rett til å eksekvere en fil, uansett om filen er lesbar for dem.

Tilgang: semantikk og attributter

Det er to grunnleggende former for tilgang; passiv og aktiv tilgang, dvs read-only og read-write. Gollmann kaller disse for Observe and Alter. Semantikken for filaksess spesifiserer hva flere brukere kan gjøre med filer samtidig. Dette har med låser å gjøre (read-only lock, eller read-write locks). Tenk tilbake til kurset i operativsystemer . Sett fra ulike brukeres sider påvirkes filintegritet av slik semantikk. I Unix går det an, for eksempel, å endre en fil mens en annen bruker leser den. Dette kan forårsake problemer for den prosessen som leser filen. Unix tilbyr en løsning som kun er basert på frivillig tilgangskontroll (Discretionary Access Control (DAC)): flock() funksjonen. Andre filsystemer hindrer skrivetilgang til filer ufrivillig (mens andre leser fra dem) (Mandatory Access Control (MAC)).

I en sikkerhets modell som vi kommer til å se nærmere på neste uke (Bell-LaPadula modellen), settes rettigheter forskjellig for disse to tilfellene. Vi får en tabell eller matrise:

             | execute | append |  read  |  write
    -------------------------------------------------
    observe  |   X     |        |   X    |    
    ------------------------------------------------- 
    alter    |         |   X    |        |    X
    -------------------------------------------------
De fleste modeller er ikke så raffinerte. Forløperen for nesten alt som brukes i dag er det historiske Multics systemet.

Filrettigheter

Operativsystemer bruker flere filsystemmodeller. Noen har komplekse rettighetsmodeller slik som Access Control Lists (ACL) som kan være vanskelige å forstå, mens andre har enkel men begrenset funksjonalitet. I praksis er mye av den fancy funskjonaliteten i moderne filsystemer bortkastet fordi brukere ikke kan forstå hvordan de skal sikre sine filer, og gir opp å prøve. Også det å vedlikeholde ACLer er vanskelig, slik at systemet kan bli usikkert bare fordi det er vanskelig å jobbe med ACLer.

NT model (NTFS)

NTFS modellen bruker ACLer. Hver fil eies av en bruker. Hver bruker tilhører et antall grupper. Hver fil har en ACL hvor tilgang kan tillates eller nektes en bestemt liste med brukere og/eller grupper. Med andre ord---vi kan kode enten en regel eller et unntak til en regel. Tilgangsmodellen bruker følgende attributter: Legg merke til hvordan noen av attributtene begrenser funksjonalitet mens andre begrenser tilgang.

Unix modell

Unix innførte en enkel modell for filrettigheter på 70-tallet som har vist seg å være ganske effektiv og lett å forstå. I de senere år har Unix også innført ACLer (men ustandardisert), men få installasjoner bruker disse på grunn av kompleksiteten og manglende standarder.

I den originale Unix modellen har hver fil tre kategorier med brukere: User (u), Group (g) and Other (o). En hvilken som helst bruker kan være medlem i et hvilket som helst antall grupper:

Hver fil har en eier og en gruppe attributt, og et sett med rettighetsbits:

for hver av kategoriene. Obs at en begrensning i denne modellen er at en fil kan være et medlem av bare en gruppe om gangen.

Hoved begrensningen i Unix modellen er at vanlige brukere ikke har rett til å lage sine egne grupper. På denne måten skyter modellen seg selv i foten! Det fins løsninger for å komme rundt dette problemet, men Unix har ikke innført en standardisert løsning på problemet. Unix modellen kan betraktes som en grov approksimasjon til ACL modellen.

Andre filesystemer

Mange andre filsystemer har blitt utviklet gjennom tidene. ACL modellen brukes i økende grad, men hver filsystemdesigner innfører nye attributter, med speiselle egenskaper. Dette gjør disse meget vanskelige å forstå for uerfarne brukere. Andre filsystemer er f. eks. AFS, DFS. Disse filsystemene kan installeres på Unix og andre systemer og har sikkerhetsmodeller som er egnet et verdens-dekkende filtre.
DFS rettigheter. Nye filer arver ACLene fra foreldre directoryet. Disse har
følgende attributter som kan settes for 
en liste med brukere, eller grupper eller "others", i den Unix-betydningen.

 r Ability of open and read a file or
   directory contents.
 w Ability to open and write to a file or
   to add files to a directory.
 x Ability to execute files as programs
   or enter directories.
 d Ability to erase (delete) a file or
   directory.
 c Ability to modify file attributes 
   including rename.
 i Ability to add files to a directory

AFS rettigheter. Disse flaggene kan settes for brukere, grupper
men ikke "others".
Fire forkortelser eksisterer write=rlidwk,
read=rl, all=rlidwka, og none fjerner en listeenhet.

 r Ability of open and read a file or 
   directory contents.
 l Lookup within a directory.
 w Ability to open and write to a file.
 i Ability to insert files in directories.
 d Ability to erase (delete) a file or
   directory.
 a Ability to modify file attributes 
   including rename.
 k Lock files.

Arv

En annen sak i forbindelse med filsikkerhet er hvilke rettigheter nye filer får i utgangspunktet. Dette er operativsystemavhengig. I listen nedenfor husk at det er få rene BSD/SYSV systemer igjen: de fleste Unix systemer er en blanding.

Prosesser

Tilgangskontroll gjelder ikke bare diskfiler men en hvilken som helst systemressurs. Retten til å kommunisere med, styre eller be om tjenester, for eksempel. Den samme ideen gjelder, men tilgangskontroll bruker forskjellige attributter. Prosessrettigheter settes vanligvis med ACLer, eller på grunnlag at protokoller, passord, nøkler eller cookies (beskjeden i en fortune cookie).

Unix prosesser har en eier og en gruppe-eier. Disse arves vanligvis fra henholdsvis brukeridentitet og programfil-gruppe (men se lenger ned om setuid/setgid programmer). Hver prosess har rettigheter i samsvar med disse merkelappene.

Kernel: To-modus-operasjon og beskyttelsesringer

Den grunnleggende sikkerheten i et flerbrukeroperativsystem hviler på muligheten til å begrense privilegier. Et av designkriteriene vi diskuterte in den første forelesningen var muligheten til å hindre slemme brukere fra å komme rundt sikkerhetsmekanismer. I noen operativsystemer har dette vært mulig når minne korrupteres. Siden software ofte har bugs, bør vi ikke stole for mye på software systemer. Vi trenger en sterkere forsikring mot minnekorrupsjon. Dette var ideen bak to-modus operasjon. (se operativsystem kursnotatene). Ved å ha en beskyttelsesmekanisme i hardware, blir systemet sikrere (da er det ikke mulig å omgå mekanismen). Multics benyttet en generalisering av denne ideen til flere enn to forskjellige tilstander. Et hierarki av beskyttelsesringer ble brukt
  1. Operating system kernel
  2. Operating system
  3. Utilities
  4. User processes
I Unix to-modus operasjon ble bare ring 0 og 3 brukt. Dette har gjort det lettere å porte Unix til mange forskjellige prosessorer med støtte for to-modus operasjon (inkludert PCer etter i386).

Rollebaserte rettigheter

I en dynamisk, interaktiv situasjon kunne man tenke seg å generalisere tilgangskontroll til å gi brukere rettigheter avhengig av hva de holder på med. Dette kan gjøres på forskjellige måter Unix setuid programmer er et eksempel hvor rettighetene til et program kan forandres (av superuser eller eier) slik at man gir spesifikke privilegier til å utføre operasjoner med en annen brukeridentitet og privilegier som tilsvarer den brukeren, uten autentisering. Setgid biten fungerer på likt vis for grupper. Merk at setuid programmer som gir for mye privilegier har vært det største sikkerhetsproblemet for Unix. (Linux skrur av muligheten for scripter)

Service access: TCP wrappers

TCP wrappers er et grensesnitt (wrapper) som tillater eller nekter adgang til nettverkstjenester på hostnivået. Det bruker ACLer hvor attributtene er maskinnavn og IP adresser, f.eks. /etc/hosts.allow
in.fingerd: 128.39.89. 128.39.74. 128.39.75.
in.cfingerd: 128.39.89. 128.39.74. 128.39.75.
sendmail: ALL
cfd: .iu.hio.no LOCAL
in.ftpd: ALL 
ftpd: ALL
in.telnetd: LOCAL .iu.hio.no 129.240.86.20

# Portmapper doesn't understand DNS for security
portmap: 128.39.89. 128.39.74. 128.39.75.
rpc.mountd: 128.39.89. 128.39.74. 128.39.75.
rpc.nfsd: 128.39.89. 128.39.74. 128.39.75.    
On Windows 2000, the network and dialup connections control panel, one has TCP/IP filtering which is like TCP wrappers
TCP ports      |   UDP ports    |  IP protocols
Permit Only    |  Permit Only   |   Permit Only
-------------------------------------------------
  21           |                |   4
  80           |                |
  443          |                |

Nettverkstilgang: Brannmurer

Routere kan drive tilgangskontroll på datagrampakker, hvor attributtene er: En brannmur blokkerer tilgang på nettverksnivået.
For instance, Cisco IOS rules:

ip access-group 100 in
access-list     100 permit tcp 0.0.0.0 255.255.255.255 host 128.39.74.16 eq http
access-list     100 permit tcp any                     host 128.39.74.16 eq smtp
access-list     100 deny   ip  any                     any

Modern versions of operating systems can filter IP packets in the kernel too, giving hosts effectively a host-based firewall. For instance, Linux has "IP chains":

ipchains -N newchain                               # new ACL/chain
ipchains -A newchain -p tcp -s 0/0 smtp -j ACCEPT  # -s source address
ipchains -A newchain -p tcp -s 0/0  www -j ACCEPT
ipchains -A newchain -j DENY                       # all else

The CIDR notation 0/0 is the same as 0.0.0.0 255.255.255.255, or "any". Windows 2000 has corresponding "IPSec filters". and the local security policy has an IP filter list.

Description|Protocols|Source port|Destination port|Source address|Destination address
-------------------------------------------------------------------------------------
   FTP     |   TCP   |  ANY      |       21       | Any IP       |  My IP
   HTTP    |   TCP   |  ANY      |       80       | Any IP       |  My IP

Generaliserte tilgangsgittere

La oss til slutt generalisere ideen om tilgangskontroll ved å abstrahere geometrisk en situasjon hvor det er flere kontrollpunkter eller tilgangsmonitorer.

Anta at vi ønsker å sende brukere gjennom en spesiell sekvens med autentiseringer og tilgangskontroller. Tenk f. eks. på en flyplass. Først går man gjennom innsjekking, så passkontroll og bagasjekontroll, og til slutt sjekkes boardingkortet. Det er ikke mulig å utføre disse kontrollene i en annen rekkefølge, da noen er avhengige av andre, men i noen tilfeller går det an å gå tilbake og likevel beholde legitimasjonen til å kunne gå fremover igjen.

Ikke-kommutativ tilgang dreier seg om å tvinge brukere gjennom tilgangskontroller i en spesiell rekkefølge. Det trenger ikke være en unik fremgangsmåte, men vi trenger en delvis ordnet rekkefølge. Dersom vi trenger N separate kontroller, kan vi tegne prosessen geometrisk ved å innbille oss at sjekkene er vektorer langs kantene av en kube eller gitter. En N dimensjonal kube er vanskelig å forestille seg, men man ser poenget med bare 3 dimensjoner, hvor kontrollene har merkelappene (x,y,z):

                          ---------   (x,y,z)
                        / |        /|
                       /  |       / |
                       ----------   |
                      |   |      |  |
                      |  / ----- |  /
                      | /        | /
                      |/         |/
                       ----------
                 (0,0,0)
Kantene av gitteret representerer ulike ruter fra ingen tilgang med (0,0,0) til full-tilgang ved (x,y,z), vårt sete på flyet, for eksempel. Vi kan bevege oss langs en kant bare hvis vi har tilgang. Ordnet tilgangskontroll betyr at ikke alle veiene er åpne. Det er som å traversere en labyrint.

Dette er bare en abstrakt representasjon på tilgangskontroll, men det gir en attraktiv geometrisk måte å visualisere avhengighetene på. I tillegg vet vi at det fins en fundamental kobling mellom gittere og matrise-algebra

Ukens tanke

I strukturert programmering finnes det globale og lokale variabler. I objekt orientering, kalles disse for offentlige og private objekter. Hva er sammenhengen mellom dette og tilgangskontroll? Hvordan tillates tilgang? Fins det noen autentisering?

Back