Sikkerhed i Java sandkasse-modellen

Siden lanceringen har Java forbeholdt en vigtig rolle i sikkerhedsspørgsmål. Skønt med blandede resultater, har designerne forsøgt at skabe platform sikringssystemer implementeret direkte i forhold til sprog, til rådighed for udviklere.

I en kontinuerlig proces med udvikling og raffinering af JVM er blevet en af de vigtigste infrastruktur til stand-alone, web, mobil og meget mere, i denne artikel vil vi fokusere på udviklingen af den sikkerhed modellen, kaldet en sandkasse i en kommentar til design fejl og den aktuelle status.

Forudsætninger

Denne artikel er rettet til alle, uanset om de er erfarne Java-programmører, der faster helt læsere af emnet. Nogle overvejelser vil blive mere forståelig for dem, der allerede har nogen erfaring med dette sprog, men læsning af denne artikel er egnet til enhver læser.

Sandkassen

Den oprindelige model

Den oprindelige model, kendt som sandkassen var designet til at begrænse potentielt skadelig kode i et isoleret miljø, og meget restriktiv. Java siden sin fødsel, var stærkt orienteret mod netværk og dette hensyn har ført til at udtænke en henrettelse model, hvor koden blev hentet direkte fra fjernbetjeningen, og udsætter klienten til betydelige sikkerhedsproblemer.

I sin første implementering, vist skematisk i figuren sandkassen kun ca skelne mellem lokale og fjernkørsel af kode: den første var nyder fuld adgang til alle ressourcer "kritiske" system som for eksempel, filsystemer og forskellige enheder, fjernkørsel Tværtimod haft begrænset adgang til ressourcer, medieret af den samme sandkasse: applets, nu stort set forsvundet fra nettet, har jeg været det bedst kendte eksempel.

Denne model indeholder en række sikkerheds-mekanismer på forskellige niveauer. Først og fremmest, Java er type-safe, dvs der er en klar sammenhæng mellem en variabel og kontrolleret og dets type (heltal, floating point, snor osv. ..).
De, der har programmeret i sprog med lav / mid-niveau såsom C og C + +, hvor mange problemer kan undgås denne kontrol: det sæt af implicitte konvertering mellem typer, såsom heltal eller boolsk ugyldig henvisninger til anden, pegepinde, som er karakteristiske for disse sprog på samme tid blevet den vigtigste kilde til programmering fejl, lige forpligtet til både begyndere og eksperter. For at minimere muligheden for, at den udvikling gjorde brølere, designerne hos Sun indført nogle aspekter hidtil kun fundet i niche eller universitet niveau sprog som for eksempel automatiske hukommelse forvaltning (garbage collection), og kontroller på run-time Access Memory (pegepinde, array elementer, etc. ...).

Det andet niveau af beskyttelse er garanteret af den compiler og kør-tid ved den virtuelle maskine. Dette sikrer, at den bytekode, den montør af Java VM er udført med den rette udføre tilladelser. Især definere to nøglekomponenter, de SecurityManager og ClassLoader, et lokalt navn, plads til at undgå interferens mellem de forskellige forekomster af VM og styre adgangskontrol til kritiske ressourcer.

JDK 1.1 - code underskrevet

Den fremlagte model er meget fleksibel og i den første opdatering af JDK (version 1.1) blev introduceret til begrebet betroede kode for at tillade eksterne applikationer, hvis de ledsages af en elektronisk underskrift godkendt af klienten, adgang til systemressourcer. Den løsning, der er skitseret i nedenstående figur, er lidt mere end et hack af den tidligere arkitektur og kræver derfor en komplet omskrivning i den næste udgivelser.

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