Programiranje

Varnost in arhitektura nalagalnika razredov

Prejšnja 1 2 Stran 2 Stran 2 od 2

Nalagalci razredov in imenski prostori

Za vsak razred, ki ga naloži, JVM spremlja, kateri nalagalnik razredov - bodisi prvotni ali objektni - je naložil razred. Ko se naloženi razred prvič sklicuje na drug razred, navidezni stroj zahteva referenčni razred od istega nalagalnika razredov, ki je prvotno naložil referenčni razred. Na primer, če navidezni stroj naloži razred Vulkan prek določenega nalagalnika razredov bo poskusil naložiti vse razrede Vulkan se nanaša na isti razred nakladalnika. Če Vulkan se nanaša na razred z imenom Lava, morda s klicanjem metode v razredu Lava, bo zahteval navidezni stroj Lava iz nakladalnika razreda, ki se je naložil Vulkan. The Lava razred, ki ga vrne nalagalnik razredov, je dinamično povezan z razredom Vulkan.

Ker JVM uporablja ta pristop pri nalaganju razredov, lahko razredi privzeto vidijo samo druge razrede, ki jih je naložil isti nalagalnik razredov. Na ta način arhitektura Jave omogoča ustvarjanje več imenski prostori znotraj ene same aplikacije Java. Prostor imen je nabor enoličnih imen razredov, ki jih naloži določen nalagalnik razredov. Za vsak nalagalnik razredov JVM vzdržuje imenski prostor, ki ga zapolnijo imena vseh razredov, ki so bili naloženi prek tega nalagalnika razredov.

Ko je JVM naložil razred z imenom Vulkan v določen imenski prostor, na primer, ni mogoče naložiti drugega razreda z imenom Vulkan v isti imenski prostor. Naložite lahko več Vulkan razredov v JVM, ker lahko znotraj aplikacije Java ustvarite več imenskih prostorov. To lahko storite preprosto z ustvarjanjem večnamenskih nakladalcev. Če ustvarite tri ločene imenske prostore (po enega za vsakega od treh nalagalcev razreda) v delujoči aplikaciji Java, potem z nalaganjem enega Vulkan razreda v vsak imenski prostor, lahko vaš program naloži tri različne Vulkan razrede v svojo aplikacijo.

Aplikacija Java lahko ustvari več predmetov nalagalnika razredov iz istega razreda ali iz več razredov. Zato lahko ustvari toliko (in toliko različnih vrst) predmetov nalagalnika razreda, kolikor jih potrebuje. Razredi, ki jih nalagajo različni nalagalniki razredov, so v različnih imenskih prostorih in ne morejo dobiti dostopa drug do drugega, razen če aplikacija tega izrecno dovoli. Ko pišete aplikacijo Java, lahko ločite razrede, naložene iz različnih virov, v različne imenske prostore. Na ta način lahko z arhitekturo nalagalnika razredov Java nadzirate kakršno koli interakcijo med kodo, naloženo iz različnih virov. Sovražni kodi lahko preprečite dostop in prijazno kodo in jo spodkopa.

Razredni nakladalniki za programčke

Primer dinamične razširitve z nalagalci razredov je spletni brskalnik, ki s pomočjo predmetov nalaganja razredov prenese datoteke razredov za programček po omrežju. Spletni brskalnik sproži aplikacijo Java, ki namesti objekt nalagalca razreda - običajno imenovan nalagalnik razreda apletov - ki zna zahtevati datoteke razredov s strežnika HTTP. Apleti so primer dinamične razširitve, ker ko se program Java zažene, ne ve, katere datoteke razredov bo brskalnik zahteval, da jih prenese po omrežju. Datoteke razreda, ki jih želite prenesti, se določijo med izvajanjem, saj brskalnik naleti na strani, ki vsebujejo javanske programčke.

Aplikacija Java, ki jo zažene spletni brskalnik, običajno ustvari drugačen objekt nalagalca razreda apletov za vsako lokacijo v omrežju, iz katere pridobi datoteke razredov. Kot rezultat, datoteke razredov iz različnih virov naložijo različni predmeti nalagalcev razredov. To jih postavi v različne imenske prostore znotraj gostiteljske aplikacije Java. Ker so datoteke razredov za programčke iz različnih virov postavljene v ločene imenske prostore, koda zlonamernega programčka ne sme neposredno posegati v datoteke razredov, prenesene iz katerega koli drugega vira.

Sodelovanje med razrednimi nakladalci

Pogosto se objekt nalagalca razredov zanaša na druge nalagalnike razredov - vsaj na prvotni nalagalnik razredov -, da mu pomaga izpolniti nekatere zahteve za nalaganje razreda, ki se pojavijo. Na primer, predstavljajte si, da pišete aplikacijo Java, ki namesti nalagalnik razredov, katerega poseben način nalaganja datotek razreda dosežemo tako, da jih prenesemo v omrežje. Predpostavimo, da je med izvajanjem aplikacije Java iz vašega nalagalnika razredov podana zahteva za nalaganje razreda z imenom Vulkan.

Eden od načinov, kako lahko napišete nalagalnik razredov, je, da najprej zahteva, da prvotni nalagalnik razredov poišče in naloži razred iz njegovega zaupanja vrednega repozitorija. V tem primeru od Vulkan ni del Java API-ja, predpostavimo, da prvotni nalagalnik razredov ne najde razreda z imenom Vulkan. Ko se prvotni nalagalnik razreda odzove, da ne more naložiti razreda, lahko nato naloži razred naloži Vulkan razred na svoj način po meri, tako da ga prenesete po omrežju. Ob predpostavki, da je nalagalnik predavanj lahko prenesel razred Vulkan, to Vulkan class bi lahko nato igral vlogo pri nadaljnjem poteku aplikacije.

Če želite nadaljevati z istim primerom, predpostavimo, da je nekaj časa pozneje metoda predavanja Vulkan se prikliče prvič in da se metoda sklicuje na razred Vrvica iz Java API. Ker izvajani program prvič uporabi referenco, navidezni stroj vpraša nalagalnik vašega razreda (tistega, ki se je naložil Vulkan) naložiti Vrvica. Kot prej, vaš nalagalnik razredov najprej posreduje zahtevo prvotnemu nalagalniku razredov, toda v tem primeru lahko nalagalnik razredov vrne Vrvica razred nazaj v nalagalnik predavanj.

Nakladaču prvobitnega razreda najverjetneje ni bilo treba dejansko naložiti Vrvica v tem trenutku, ker glede na to Vrvica je tako temeljni razred v programih Java, skoraj zagotovo je bil uporabljen že prej in zato že naložen. Najverjetneje je prvotni nalagalnik razreda pravkar vrnil datoteko Vrvica razred, ki ga je že naložil iz zaupanja vrednega repozitorija.

Ker je prvotni nalagalnik razreda uspel najti razred, ga vaš nalagalnik razredov ne poskuša prenesti po omrežju; samo prenese na virtualni stroj Vrvica razred, ki ga vrne nalagalnik prvotnega razreda. Od tega trenutka naprej virtualni stroj to uporablja Vrvica razred, kadarkoli razred Vulkan se sklicuje na razred z imenom Vrvica.

Razredni nakladalci v peskovniku

V peskovniku Java je arhitektura razreda nalagalcev prva obrambna linija pred zlonamerno kodo. Nakladnik razredov navsezadnje pripelje kodo v kodo JVM, ki je lahko sovražna.

Arhitektura nalagalnikov razredov prispeva k peskovniku Java na dva načina:

  1. Zlonamerni kodi preprečuje motenje dobronamerne kode.
  2. Varuje meje zaupanja vrednih knjižnic razredov.

Arhitektura nalagalnika razredov varuje meje knjižnic zaupanja vrednih razredov tako, da se prepriča, da se nezaupani razredi ne morejo pretvarjati, da so jim zaupali. Če bi lahko zlonamerni razred JVM uspešno prevaral, da bi šlo za zaupanja vreden razred iz Java API-ja, bi ta zlonamerni razred lahko prodrl skozi pregrado peskovnika. Arhitektura nalagalnika razredov preprečuje, da bi se nezaupljivi razredi lažno predstavljali kot zaupanja vredni razredi, in sicer tako, da ogrozijo varnost izvajalnega okolja Java.

Imenski prostori in ščiti

Arhitektura nalagalnika razredov preprečuje, da bi zlonamerna koda posegala v dobronamerno kodo, tako da nudi zaščitene imenske prostore za razrede, ki jih nalagajo različni nalagalniki razredov. Kot je bilo omenjeno zgoraj, imenski prostor je nabor enoličnih imen za naložene razrede, ki ga vzdržuje JVM.

Imenski prostori prispevajo k varnosti, saj lahko dejansko postavite ščit med razrede, naložene v različne imenske prostore. Znotraj JVM lahko razredi v istem imenskem prostoru neposredno komunicirajo med seboj. Predavanja v različnih imenskih prostorih pa ne morejo zaznati niti prisotnosti drug drugega, razen če izrecno navedete mehanizem, ki omogoča medsebojno interakcijo razredov. Če bi zlonamerni razred, ko je bil naložen, imel zagotovljen dostop do vseh drugih razredov, ki jih trenutno nalaga navidezni stroj, bi se ta razred lahko naučil stvari, ki jih ne bi smel vedeti, ali pa bi lahko motil pravilno izvajanje vašega programa.

Ustvarjanje varnega okolja

Ko napišete aplikacijo, ki uporablja nalagalnike razredov, ustvarite okolje, v katerem deluje dinamično naložena koda. Če želite, da v okolju ni nobenih varnostnih lukenj, morate pri pisanju nalagalcev aplikacij in razredov upoštevati določena pravila. Na splošno boste želeli napisati svojo aplikacijo, tako da bo zlonamerna koda zaščitena pred dobronamerno kodo. Prav tako boste želeli napisati nalagalnike razredov tako, da bodo zaščitili meje zaupanja vrednih knjižnic razredov, kot so Java API.

Imenski prostori in viri kode

Če želite dobiti varnostne prednosti, ki jih ponujajo prostori imen, morate zagotoviti, da razrede naložite iz različnih virov prek različnih nalagalnikov razredov. To je zgoraj opisana shema, ki jo uporabljajo spletni brskalniki, ki podpirajo Javo. Aplikacija Java, ki jo sproži spletni brskalnik, običajno ustvari drugačen objekt nalagalca razreda apletov za vsak vir razredov, ki jih prenese v omrežje. Na primer, brskalnik bi uporabil en predmet nalagalca razredov za prenos razredov z //www.niceapplets.com, drug objekt nalagalca razredov pa za prenos razredov z //www.meanapplets.com.

Varovanje omejenih paketov

Java dovoljuje, da razredi v istem paketu drug drugemu podelijo posebne pravice dostopa, ki niso dodeljene razredom zunaj paketa. Torej, če vaš nalagalnik razredov prejme zahtevo za nalaganje razreda, ki se s svojim imenom drzno izjavi, da je del Java API-ja (na primer razred z imenom java.lang.Virus), vaš razredni nakladalnik naj ravna previdno. Če je naložen, lahko tak razred pridobi poseben dostop do zaupanja vrednih razredov java.lang in bi ta poseben dostop morda lahko uporabil za neprijetne namene.

Zato bi običajno napisali nalagalnik razredov, tako da preprosto noče naložiti nobenega razreda, ki trdi, da je del Java API-ja (ali katere koli druge zanesljive izvajalne knjižnice), ki pa ne obstaja v lokalnem zaupanja vrednem repozitoriju. Z drugimi besedami, potem ko nalagalnik razredov pošlje zahtevo prvotnemu nalagalniku razredov in ko nalagalnik prvotnega razreda nakaže, da ne more naložiti razreda, mora vaš nalagalnik razredov preveriti, ali se razred ne razglasi za člana zaupanja vrednega paketa. Če se to zgodi, bi moral vaš nalagalnik razredov, namesto da bi poskušal prenesti razred po omrežju, vrniti varnostno izjemo.

Varovanje prepovedanih paketov

Poleg tega ste morda v zaupanja vredni repozitorij namestili nekatere pakete, ki vsebujejo razrede, za katere želite, da jih aplikacija lahko naloži skozi prvotni nalagalnik razredov, vendar ne želite, da so razredi naloženi prek nalagalnika razredov. Denimo, da ste ustvarili paket z imenom absolutna moč in ga namestil v lokalno repozitorij, do katerega je lahko nalagal prvotni razred. Predpostavimo tudi, da ne želite, da bi razredi, ki jih naloži nalagalnik razredov, lahko naložili kateri koli razred iz absolutna moč paket. V tem primeru bi napisali svoj nalagalnik razredov tako, da se najprej prepričate, da se zahtevani razred ne izjavi kot član absolutna moč paket. Če se zahteva tak razred, bi moral vaš nalagalnik razredov namesto, da bi predaval ime razreda prvotnemu nalagalniku razredov, vrgel varnostno izjemo.

Nalagalnik razredov lahko edino ve, ali je razred iz omejenega paketa, na primer java.lang, ali prepovedan paket, kot je absolutna moč, je po imenu razreda. Tako mora nalagalnik razredov dobiti seznam imen omejenih in prepovedanih paketov. Ker ime razreda java.lang.Virus pomeni, da je iz java.lang paket in java.lang je na seznamu omejenih paketov, bi moral vaš nalagalnik razredov vrniti varnostno izjemo, če je prvotni nalagalnik razreda ne more naložiti. Prav tako tudi zato, ker je ime predavanja absolutepower.FancyClassLoader pomeni, da je del absolutna moč paket in absolutna moč paket na seznamu prepovedanih paketov, bi moral vaš nalagalnik razredov vrniti varnostno izjemo.

Varnostno naravnan nakladalnik razreda

Običajni način pisanja nalagalnika razredov, ki skrbi za varnost, je uporaba naslednjih štirih korakov:

  1. Če obstajajo paketi, iz katerih tega nalagalnika razredov ni dovoljeno naložiti, nalagalnik razredov preveri, ali je zahtevani razred v enem od zgoraj omenjenih prepovedanih paketov. Če je tako, vrže varnostna izjema. V nasprotnem primeru nadaljujemo z drugim korakom.

  2. Nalagalnik razredov posreduje zahtevo prvotnemu nalagalniku razredov. Če prvotni nalagalnik razreda uspešno vrne razred, nalagalnik razreda vrne isti razred. V nasprotnem primeru nadaljuje s tretjim korakom.

  3. Če obstajajo zaupanja vredni paketi, ki jim nalagalnik razredov ne sme dodajati razredov, nalagalnik razredov preveri, ali je zahtevani razred v enem od teh omejenih paketov. Če je tako, vrže varnostna izjema. V nasprotnem primeru nadaljujemo s četrtim korakom.

  4. Nazadnje, nalagalnik razredov poskuša razred naložiti po meri, na primer tako, da ga prenese v omrežje. Če je uspešen, vrne razred. Če je neuspešen, vrže napako "ni mogoče najti definicije razreda".

Z izvajanjem prvega in tretjega koraka, kot je opisano zgoraj, nalagalnik razreda varuje meje zaupanja vrednih paketov. Z prvim korakom preprečuje, da bi se razred iz prepovedanega paketa sploh naložil. V tretjem koraku nezaupljivemu razredu ne dovoli, da se vstavi v zaupanja vreden paket.

Zaključek

Arhitektura razrednega nakladalnika prispeva k varnostnemu modelu JVM na dva načina:

  1. z ločevanjem kode v več imenskih prostorov in postavitvijo "ščita" med kodo v različnih imenskih prostorih
  2. z varovanjem robov zaupnih knjižnic razredov, kot je Java API

Obe zmožnosti arhitekture nalagalnikov razredov Java morajo programerji pravilno uporabiti, da izkoristijo varnostne koristi, ki jih ponujajo. Da bi izkoristili ščit prostora prostora z imeni, je treba kodo iz različnih virov naložiti skozi različne predmete nalagalcev razredov. Če želite izkoristiti zaupanja vredno mejo paketov, je treba v nalagalnike razredov zapisati imena zahtevanih razredov na seznamu omejenih in prepovedanih paketov.

Za sprehod skozi postopek pisanja nalagalnika razredov, vključno z vzorčno kodo, glejte Chuck McManis's JavaWorld članek, "Osnove nalagalcev razreda Java."

Naslednji mesec

V članku prihodnjega meseca bom nadaljeval razpravo o varnostnem modelu JVM z opisom preveritelja razreda.

Bill Venners že 12 let profesionalno piše programsko opremo. S sedežem v Silicijevi dolini ponuja svetovanje in izobraževanje o programski opremi pod imenom Artima Software Company. Z leti je razvil programsko opremo za potrošniško elektroniko, izobraževanje, polprevodniške in življenjske zavarovalne panoge. Programiral je v številnih jezikih na številnih platformah: montažni jezik na različnih mikroprocesorjih, C na Unixu, C ++ na Windows, Java na spletu. Je avtor knjige Inside the Java Virtual Machine, ki jo je izdala McGraw-Hill.

Preberite več o tej temi

  • Knjiga Specifikacija Java navideznega stroja (//www.aw.com/cp/lindholm-yellin.html), Tim Lindholm in Frank Yellin (ISBN 0-201-63452-X), del serije Java (//www.aw.com/cp /javaseries.html), od Addison-Wesley, je dokončna referenca za navidezni stroj Java.
  • Zaščiteno računalništvo z JavaNow in prihodnost (tehnični dokument) // www.javasoft.com/marketing/collateral/security.html
  • Pogosta vprašanja o varnosti apletov

    //www.javasoft.com/sfaq/

  • Nizka raven varnosti v Javi, avtor Frank Yellin //www.javasoft.com/sfaq/verifier.html
  • Domača stran Java Security

    //www.javasoft.com/security/

  • Oglejte si domačo stran sovražnih apletov

    //www.math.gatech.edu/~mladue/HostileApplets.html

  • Knjiga Java Security - sovražni programčki, luknje in protistrupi, dr. Garyja McGrawa in Eda Feltona, poda temeljito analizo varnostnih vprašanj, povezanih z Javo. //www.rstcorp.com/java-security.html
  • Prejšnji članki "Pod pokrovom":
  • Lean, Mean Virtual Machine - predstavlja uvod v navidezni stroj Java.
  • Življenjski slog datoteke razreda Java - daje pregled datoteke razreda Java, oblike zapisa, v katero so zbrani vsi programi Java.
  • Java's Garbage-Collected Heap - daje pregled zbiranja smeti na splošno in zlasti kup zbranega smeta navideznega stroja Java.
  • Osnove bytecode - predstavi bytecode navideznega stroja Java in obravnava predvsem primitivne tipe, operacije pretvorbe in operacije sklada.
  • Aritmetika s plavajočo vejico - opisuje podporo za plavajočo vejico navideznega računalnika Java in bajtode, ki izvajajo operacije s plavajočo vejico.
  • Logic and Arithmetic - opisuje podporo Java navideznega računalnika za logično in celoštevilčno aritmetiko ter s tem povezane bajtode.
  • Predmeti in nizi - opisuje, kako navidezni stroj Java obravnava predmete in nize, ter obravnava ustrezne bajtode.
  • Izjeme - opisuje, kako se navidezni stroj Java ukvarja z izjemami, in obravnava ustrezne bajtode.
  • Poskusi končno - opisuje, kako navidezni stroj Java izvaja klavzule poskusi končno, in razpravlja o ustreznih bajtokodih.
  • Control Flow - opisuje, kako navidezni stroj Java izvaja nadzorni tok, in obravnava ustrezne bajtode.
  • Arhitektura Aglets - opisuje notranje delovanje agletov, IBM-ove avtonomne tehnologije programske opreme, ki temelji na Javi.
  • The Point of Aglets - Analizira dejansko uporabnost mobilnih agentov, kot so aglets, IBM-ova avtonomna tehnologija programske opreme, ki temelji na Javi.
  • Priklic in vrnitev metode - opisuje štiri načine, kako navidezni stroj Java prikliče metode, vključno z ustreznimi bajtkodami.
  • Sinhronizacija niti - prikazuje, kako deluje sinhronizacija niti v navideznem računalniku Java. Obravnava bajtode za vstop in izhod iz monitorjev.
  • Javna varnostna arhitektura - daje pregled varnostnega modela, vgrajenega v JVM, in vpogled v vgrajene varnostne funkcije JVM.

To zgodbo "Varnost in arhitektura nalagalcev razredov" je prvotno objavil JavaWorld.

$config[zx-auto] not found$config[zx-overlay] not found