Säkerhet i Java sandlåda modell

Sedan introduktionen har Java reserverat en viktig roll i säkerhetsfrågor. Även med blandade resultat, har designers försökt ge systemplattform säkerhet implementeras direkt i termer av språk, tillgängligt för utvecklare.

I en kontinuerlig process av utveckling och förfining av JVM har blivit en av de viktigaste infrastrukturen för fristående, webb, mobil och mer, i denna artikel kommer vi att fokusera på utvecklingen av säkerheten modellen, som brukar kallas en sandlåda i en kommentar till konstruktionsfel och aktuell status.

Förutsättningar

Den här artikeln riktar sig till alla, oavsett om de är erfarna Java-programmerare som fastar helt läsare av ämnet. Vissa överväganden kommer bli mer begripliga för dem som redan har viss erfarenhet av detta språk är dock läsningen av denna artikel lämplig för alla läsare.

Sandlådan

Den ursprungliga modellen

Den ursprungliga modellen, som kallas sandlåda var utformad för att begränsa skadlig kod i en isolerad miljö, och mycket restriktivt. Java sedan dess födelse, var starkt orienterad till nätverket och detta övervägande ledde till att utforma ett utförande modell där koden var ned direkt från fjärrkontrollen, utsätter kunden för betydande säkerhetsproblem.

I sitt första genomförande, visas schematiskt i figuren, sandlådan bara ungefär skilja mellan lokala och fjärranslutna kod kod: den första var med full tillgång till alla resurser "kritiska" system såsom exempelvis filsystem och olika enheter, fjärrkontrollen koden Tvärtom hade begränsad tillgång till resurser, medieras av samma sandlåda: appletar, nu i stort sett försvunnit från nätet, jag har varit det mest kända exemplet.

Denna modell innehåller en uppsättning av säkerhetsmekanismer på olika nivåer. Först av allt, är Java typsäkert, dvs det finns en uttrycklig relation mellan en variabel och kontrollerad och dess typ (heltal, flyttal, sträng, etc. ..).
De som har programmerat i språk med låg / mid-level som C och C + + veta hur många problem kan undvikas denna kontroll: De implicita konverteringar mellan typer, som heltal eller booleska ogiltig pekare till annan pekare, som är karakteristiska för dessa språk samtidigt blir den viktigaste källan till programmeringsfel, lika engagerade både nybörjare och experter. För att minska risken att utvecklingen gjort misstag, presenterade formgivarna på Sun vissa aspekter som hittills bara finns i nisch eller universitetets språk nivå som till exempel automatisk minneshantering (sophämtning) och kontroller vid run-time Access Memory (pekare, arrayelementen, osv ...).

Den andra nivån av skydd garanteras av kompilatorn och run-time, av den virtuella maskinen. Detta säkerställer att bytekod, sammansättaren av Java VM körs med rätt körrättigheter. Framför allt två viktiga komponenter, SecurityManager och ClassLoader, definiera ett lokalt namn utrymme för att undvika störningar mellan olika instanser av VM och hantera åtkomstkontroll till kritiska resurser.

JDK 1.1 - kod undertecknad

Modellen som presenteras är mycket flexibel och i den första uppdateringen av JDK (version 1.1) introducerades begreppet betrodda kod för att möjliggöra fjärrkörning av program, om de åtföljs av en elektronisk signatur erkänts av kunden, tillgång till systemresurser. Lösningen, som beskrivs i följande figur, är lite mer än ett hack i den tidigare arkitekturen och kräver därför en fullständig omskrivning i nästa version.

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