Denne månedens "Under The Hood" -kolonnen er den første av en firedelt serie om Javas sikkerhetsmodell. De fire artiklene vil fokusere på sikkerhetsinfrastrukturen innebygd i Java virtual machine (JVM) og java.lang-biblioteket. Denne første artikkelen gir en oversikt over sikkerhetsmodellen og beskriver JVMs sikkerhetsfunksjoner.
Hvorfor sikkerhet?
Java's sikkerhetsmodell er et av språkets viktigste arkitektoniske trekk som gjør det til en passende teknologi for nettverksmiljøer. Sikkerhet er viktig fordi nettverk gir en potensiell angrepsvei til enhver datamaskin som er koblet til dem. Denne bekymringen blir spesielt sterk i et miljø der programvare lastes ned over hele nettverket og kjøres lokalt, slik det for eksempel gjøres med Java-appletter. Fordi klassefilene til en applet lastes ned automatisk når en bruker går til den inneholder websiden i en nettleser, er det sannsynlig at en bruker vil støte på applets fra ikke-klarerte kilder. Uten sikkerhet ville dette være en praktisk måte å spre virus på. Dermed hjelper Javas sikkerhetsmekanismer til å gjøre Java egnet for nettverk fordi de skaper en nødvendig tillit til sikkerheten til nettverksmobilkode.
Java's sikkerhetsmodell er fokusert på å beskytte brukere mot fiendtlige programmer lastet ned fra ikke-klarerte kilder over et nettverk. For å oppnå dette målet, gir Java en tilpassbar "sandkasse" der Java-programmer kjøres. Et Java-program må bare spilles inne i sandkassen. Den kan gjøre hva som helst innenfor grensene til sandkassen, men den kan ikke gjøre noe utenfor disse grensene. Sandkassen for ikke-klarerte Java-appletter forbyder for eksempel mange aktiviteter, inkludert:
- Lese eller skrive til den lokale disken
- Opprette en nettverkstilkobling til en hvilken som helst vert, bortsett fra verten som appleten kom fra
- Opprette en ny prosess
- Laster inn et nytt dynamisk bibliotek og direkte kaller en innfødt metode
Ved å gjøre det umulig for nedlastet kode å utføre visse handlinger, beskytter Javas sikkerhetsmodell brukeren mot trusselen om fiendtlig kode.
Sandkassen definert
Tradisjonelt måtte du stole på programvare før du kjørte den. Du oppnådde sikkerhet ved å være forsiktig med å bare bruke programvare fra pålitelige kilder, og ved regelmessig å skanne etter virus bare for å sikre at ting var trygge. Når noe programvare fikk tilgang til systemet ditt, hadde det full tøyle. Hvis det var skadelig, kan det skade systemet ditt stort fordi programvaren ikke har noen begrensninger på datamaskinens kjøretidsmiljø. Så, i det tradisjonelle sikkerhetsskjemaet, prøvde du å forhindre at ondsinnet kode noen gang fikk tilgang til datamaskinen din i utgangspunktet.
Sandkassesikkerhetsmodellen gjør det lettere å jobbe med programvare som kommer fra kilder du ikke stoler helt på. I stedet for å opprette sikkerhet ved å kreve at du forhindrer at noen kode du ikke stoler på, noen gang kommer inn på datamaskinen din, lar sandkassemodellen deg velkomstkode fra hvilken som helst kilde. Men mens den kjører, begrenser sandkassen koden fra ikke-klarerte kilder til å utføre handlinger som muligens kan skade systemet ditt. Fordelen er at du ikke trenger å finne ut hvilken kode du kan og ikke kan stole på, og at du ikke trenger å skanne etter virus. Sandkassen i seg selv forhindrer at virus eller annen ondsinnet kode du kan invitere til datamaskinen din, gjør skade.
Sandkassen er gjennomgripende
Hvis du har et skikkelig skeptisk sinn, må du være overbevist om at en sandkasse ikke har noen lekkasjer før du stoler på at den beskytter deg. For å sikre at sandkassen ikke har noen lekkasjer, involverer Javas sikkerhetsmodell alle aspekter av arkitekturen. Hvis det var områder i Java-arkitekturen der sikkerheten var svak, kunne en ondsinnet programmerer (en "cracker") potensielt utnytte disse områdene til å "gå rundt" sandkassen. For å forstå sandkassen må du derfor se på flere forskjellige deler av Java-arkitekturen og forstå hvordan de fungerer sammen.
De grunnleggende komponentene som er ansvarlige for Java's sandkasse er:
- Sikkerhetsfunksjoner innebygd i den virtuelle Java-maskinen (og språket)
- Klasselasterarkitekturen
- Klassefilverifisereren
- Sikkerhetsleder og Java API
