Model zabezpieczeń Java ClassLoader

Question

Próbuję zrozumieć model zabezpieczeń używany, gdy JVM jest żądana do ładowania klas.

Od specyfikacji JVM w Sandboxing, jestem przekonany, że standardowa implementacja maszyny JVM powinna obsługiwać co najmniej jedną inną wersję: ClassLoader, niezależnie od primordial ClassLoader. Służy do ładowania plików klas aplikacji (na przykład z udostępnionej ścieżki klasy).

Jeśli klasa jest wymagane od ClassLoader że nie jest w jego nazw, java/lang/String na przykład, a następnie przekazuje żądanie do pierwotnej ClassLoader, która próbuje załadować klasę z API Javy, jeśli nie jest tam wtedy go wyrzuca NoClassDefFoundError.

Czy mam rację sądząc, że pierwotny ClassLoader ładuje tylko klasy z przestrzeni nazw interfejsu API języka Java, a wszystkie inne klasy są ładowane za pomocą osobnej implementacji ClassLoader?

I to sprawia, że ​​ładowanie klas bardziej bezpieczne, ponieważ oznacza to, że złośliwy klasa nie może uchodzić za członka API Java (powiedzmy java/lang/Virus), ponieważ jest to obszar nazw chronione i nie mogą być wykorzystywane w bieżącej ClassLoader ?

Ale czy jest coś, co uniemożliwi zastąpienie klas interfejsu API języka Java złośliwymi klasami, czy też zostanie to wykryte podczas weryfikacji class?

Answer 1

Ze względów historycznych nazwy używane do ładowania klas są trochę dziwne. Program ładujący klasy ładujący ładuje klasy systemów. Program ładujący klasy systemu domyślnie ładuje klasy ze ścieżki klas, a nie z klas systemowych. Klasy systemowe są w jre/lib (głównie w rt.jar), wspierane katalogi i wszędzie dodane przez -Xbootclasspath.

W środowisku Sun/Oracle JRE plik rt.jar zawiera klasy z pakietami zaczynającymi się od java., Javax., Sun., Com.sun., Org.omg, org.w3c i org.xml.

Niezaufany kod (w tym konfiguracja) nie może być dodawany do klas systemowych. Niektóre nazwy pakietów z prefiksem mogą być ograniczone przez właściwość zabezpieczeń. Java. prefiks jest specjalnie chroniony przed, z powodów nietechnicznych.

Ogólnie program ładujący klasy deleguje do obiektu nadrzędnego przed zdefiniowaniem nowej klasy, co uniemożliwi wymianę żadnych klas z modułu ładującego przodka. Java EE zaleca (nawet w przypadku zakazów Java SE), że niektóre programy ładujące klasy preferują własne klasy, zazwyczaj w celu korzystania z bardziej aktualnego API lub innej implementacji. Pozwala to na zacienianie klas, ale tylko tak, jak widać to za pomocą tego programu ładującego (i jego dzieci). Wszystkie pozostałe klasy nadal łączą się z oryginałem.