Intro til ITKACL

Bakgrunn

(Dette er skrevet delvis mens implementeringen pågår, men man vet jo at ingen løsninger er så permanente som de temporære løsningene, så jeg kan like gjerne skrive det som om alt er opp- og avgjort først som sist :-P)

Sommeren 2004 kom man fram til at det ble ineffektivt i lengden å kjøre separat tilgangskontroll på alle systemer (så som AMSIT, MedlemsDB og den kommende MDB2, loginbokser osv.), spesielt mht. vedlikehold av passord (AMSIT hadde f.eks. 40 forskjellige .htpasswd-filer, mange av dem med duplikatpassord) og tilganger (det var ikke mulig å si "hele ITK har tilgang til alle AMSIT-lister", hver enkelt ITKer måtte legge seg selv til i .htpasswd-filene etter hvert som man trengte tilgang).

Derfor kom man fram til at man ønsket å lage et nytt, sentralisert system for tilgangskontroll til de systemene man etter hvert hadde utviklet. (Nytt ettersom man ikke kjente til noe eksisterende som var i nærheten av å fylle behovene man hadde.) Kravene til et slikt system var:

Sentralisert tilgangskontroll (dvs. man setter alle tilganger fra ett sentralt sted).
Sentralisert autentiseringsinformasjon (dvs. ett passord å sette og endre, ikke 40)
Enkelt å integrere mot eksisterende egne systemer i den grad det er mulig (man ønsker f.eks. neppe å skrive om Mailmans autentiseringssystem, men det går greit å integrere mot AMSIT).

Løsningen ble formulert en sen kveld i form av et hierarkisk ACL-tre for alle systemene på Samfundet; mer om hvordan ting fungerer i neste avsnitt.

Generell virkemåte

ITKACL styrer kun med autorisering, ikke autentisering. Autentisering finnes det allerede glimrende systemer for – vi har valgt å basere oss på Kerberos 5. (For de som ikke er helt sikre på forskjellen: autentisering er "er det virkelig brukeren 'sesse' som prøver å logge inn her", autorisering er "har brukeren 'sesse' lov til å aksessere dette objektet".) Brukere og grupper i ITKACL er per definisjon identisk med UNIX-brukere og -grupper. ITKACL antar at disse er like på alle maskiner systemet vil kjøres på – dette kan man enten oppnå ved å diste ut /etc/passwd og /etc/group, eller ved å bruke LDAP.

Alle objekter man ønsker å spesifisere tilgangskontroll på (f.eks. "Serveringsgjengens ASMIT-lister") har sin plass i et hierarkisk tre, som er formet som en vanlig UNIX-path (men som ikke har noe med filsystemet å gjøre overhodet), f.eks. "/web/amsit/sg".

Alle tilganger er binære; enten har man tilgang til et objekt eller så har man ikke, man kan ikke f.eks. ha "lese"-tilgang til et objekt men ikke "skrive"-tilgang (men se "meta-tilganger" under). Alle tilganger arves – dersom en person har tilgang til "/web/amsit" vil vedkommende også ha tilgang til "/web/amsit/sg" dersom det ikke settes noe spesifikt på "sg"-objektet for å forhindre dette.

Hvem som har tilgang til et objekt (og følgelig dets barn) spesifiseres av objektets såkalte ACL (Access Control List), som er en liste over hvem som skal gis (grant) eller nektes (deny) tilgang til objektet. "Hvem" i denne sammenhengen kan være enten UNIX-bruker, en UNIX-gruppe eller "alle" (som spesifiseres som gruppen "<everyone>").

Når en tjeneste ønsker å teste om en bruker har tilgang til tjenesten eller ikke, sjekkes (etter autentisering av brukeren) ACLene nedover fra roten og ned til objektet etter tur – tilganger satt på objekter lenger ned overstyrer arvede tilganger. Dersom ingen ACLer passer på brukeren, er standardvalget å nekte brukeren tilgang. (For mer informasjon om hvordan ACLer sjekkes og sorteres, se ITKACLImplementasjon.)

Alle ACLer administreres via et enkelt (og foreløpig litt rudimentært) webgrensesnitt, på https://acl.samfundet.no. Dette er selvsagt i seg selv begrenset med en ACL (på /web/itkacl); det er ingenting som hindrer en i å sperre seg selv ute fra webgrensesnittet, så pass på...

Det finnes flere forskjellige grensesnitt mot ACLene (bl.a. en Apache-modul for webtjenester, en PAM-modul for logintjenester, en Perl-modul, en Python-modul osv.), men alle snakker i bunn med det samme C-biblioteket. For mer informasjon om hvordan sette opp ACLer på sine egne systemer (f.eks. websystemer), se ITKACLBruk; for mer informasjon om hvordan programmere mot ACL-biblioteket, se ITKACLProgrammering.

Tips

Generelt er det noen prinsipper man burde tenke på når man lager ACLer og objekter:

La objekter være i små bokstaver, og hold navnene korte. Du har et beskrivelse-felt om du vil skrive noe lengre.
Ikke del opp objekter i flere underobjekter dersom du ikke har noen nytte av å differensiere tilganger. Jo mindre treet er, jo mer lettforståelig er det og jo enklere er det å vedlikeholde.
Benytt deg av at tilganger arver, samt at man kan bruke grupper, men tenk på om arven blir logisk ut fra at det kan komme til nye grupper også. Det er bedre å sette tilgang til "itk"-gruppen på "/web/amsit" enn å sette tilgang til alle enkelt-ITKere på "/web/amsit/sg", "/web/asmit/sit", "/web/amsit/lim" osv... Allikevel burde tilganger ikke settes for høyt oppe; som en tommelfingerregel burde man ikke sette tilganger på rotnodene (/web, /login osv.).

Meta-tilganger

Som tidligere nevnt er alle tilganger binære – enten har man tilgang til et objekt eller så har man det ikke. (Merk at dette ikke er en "hellig ku" eller en "design-feature"; det er gjort slik for å redusere implementasjonsbyrden og kompleksiteten. Dersom man seinere finner ut at man ønsker å lage et mer komplekst system er det bare å sende patcher :-) ) I en del tilfeller kan det imidlertid være man ønsker å differensiere tilgangen litt mer enn som så, og da kan man bruke fake-objekter for å få til dette.

La oss f.eks. si at man ønsker å differensiere tilgangen til tellesys, altså smt (/web/smt), slik at noen brukere (f.eks. gruppen "smt-view") bare kan se på dataene mens andre (f.eks. gruppen "smt-reset") også kan nullstille tellerne. Da kan man implementere dette på følgende to forskjellige måter:

Lag to nye objekter, /web/smt/view med tilgang til "smt-view" og /web/smt/reset med tilgang til "smt-reset", mens /web/smt står uten tilganger. Merk at her kan man plutselig ha folk som har tilgang til å nullstille men ikke til å se (hvorpå de dermed ikke kommer seg til nullstillingsformen!) – dette er kanskje ikke den beste løsningen i dette tilfellet.
Sett tilgang til "smt-reset" på /web/smt som vanlig, og ha et underobjekt /web/smt/view med tilgang til "smt-view". Dette vil føre til at alle som har tilgang til å nullstille samtidig automatisk har tilgang til å se (siden tilgangen fra /web/smt arver ned til /web/smt/view), men mange vil finne dette ulogisk, og man kan fort komme til å sette tilgang på "/web/smt" uten dermed å tenke på at man i realiteten gir superbruker-tilgang (dvs. tilgang til å nullstille) til systemet.

Hvilken måte man velger avhenger litt av situasjonen, særlig når man får flere enn bare to tilganger. Generelt burde man passe seg for å bruke arv kombinert med metatilganger i det hele tatt – man kan f.eks. ikke si noe ala "gruppen kkontor kan se på alle AMSIT-mailinglister, men ikke endre på noen av dem" med hverken den første eller den andre løsningen over. Hvis man ønsker noe såpass komplekst er det nok bedre å utvide systemet; "excercise left to the reader" (se ITKACLImplementasjon :-P).

Lenker: Start, itkacl, itkaclbruk, itkaclimplementasjon, utdatert dokumentasjon