Sikkerhet i Java sandkasse-modell

Siden lanseringen har Java reservert en viktig rolle i sikkerhetsspørsmål. Selv med blandede resultater, har designere søkt å gi plattform sikkerhetssystemer implementeres direkte i form av språk, tilgjengelig for utviklere.

I en kontinuerlig prosess med utvikling og foredling av JVM har blitt en av de viktigste infrastrukturen for stand-alone, web, mobil og mer, i denne artikkelen vil vi fokusere på utviklingen av sikkerheten modell, ofte kalt en sandkasse, kommenterer designfeil og gjeldende status.

Forutsetninger

Denne artikkelen er adressert til alle, enten de er erfarne Java-programmerere som faster helt lesere av emnet. Noen betraktninger vil være mer forståelig for dem som allerede har litt erfaring med dette språket, derimot, er lesing av denne artikkelen er egnet for enhver leser.

Sandkassen

Den opprinnelige modellen

Den opprinnelige modellen, kjent som sandkasse var designet for å begrense potensielt skadelig kode i et isolert miljø, og svært restriktive. Java siden fødselen sin, var sterkt orientert til nettverket, og dette hensynet førte til tenke ut en henrettelse modell der koden ble lastet ned direkte fra fjernkontrollen, utsette klienten til betydelige sikkerhetsproblemer.

I sin første gjennomføringen, vist skjematisk i figuren, sandkassen eneste omtrent skille mellom lokal og ekstern kode kode: den første var nyter full tilgang til alle ressurser "kritisk" system som for eksempel filsystemer og ulike enheter, ekstern kode Tvert imot, hadde begrenset tilgang til ressurser, mediert av det samme sandkasse: applets, nå i stor grad forsvunnet fra nettet, har jeg vært den mest kjente eksempel.

Denne modellen inneholder et sett med sikkerhet mekanismer på ulike nivåer. Først av alt, er Java type-safe, dvs. det er en eksplisitt sammenheng mellom en variabel og kontrollert og dets type (heltall, flyttall, streng, etc. ..).
De som har programmert i språk med lav / middels nivå som C og C + + vet hvor mange problemer kan unngås denne kontrollen: settet av implisitt konvertering mellom typer, slik som heltall eller boolean void pekere til andre pekere, som er karakteristisk for disse språkene samtidig blitt den viktigste kilden til programmeringsfeil, like forpliktet til både nybegynnere og eksperter. For å minimere muligheten for at utviklingen gjort tabber, introduserte designerne hos Sun noen aspekter hittil bare funnet i nisje eller universitetsnivå språk som for eksempel automatisk minnehåndtering (garbage collection) og kontroller på kjøre-time access memory (pekere, array elementer, etc. ...).

Det andre nivået av beskyttelse er garantert av kompilatoren og run-time, ved den virtuelle maskinen. Dette sikrer at ByteCode, assembler av Java VM blir utført med riktig utføre tillatelser. Spesielt to viktige komponenter, SecurityManager og ClassLoader, definere et lokalt navn plass for å unngå interferens mellom ulike forekomster av VM og styre tilgangskontroll til kritiske ressurser.

JDK 1.1 - kode signert

Modellen som presenteres er svært fleksibel og i den første oppdateringen av JDK (versjon 1.1) ble introdusert til begrepet betrodde kode for å tillate eksterne programmer, i følge med en elektronisk signatur anerkjent av klienten, tilgang til system ressurser. Løsningen, skissert i figuren nedenfor, er lite mer enn en hack av den tidligere arkitektur og derfor kreve en fullstendig omskriving i neste utgivelser.

• <<
• 1
• 2
• 3
• >>