Odporność na błędy bizantyjskie w systemach peer-to-peer - Instytut ...

88 Rozdział 5. Projekt systemu Pastor
obiektu, dlatego też wszystkie zabezpieczenia musiałyby być zrealizowane na
poziomie wątku wykonania, co dodatkowo rzutuje na wydajność. Wymagania
zapewnienia bezpieczeństwa można rozwiązać używając dwóch podejść:
• Weryfikacja typu off-line, tzn. architektura aplikacji powinna wykorzystywać
mechanizm wtyczek (ang. plug-in), które dostarczane są z wiadomego
źródła, jako zewnętrzne klasy. Uruchamiane klasy powinny być podpisane,
a ich uprawnienia zależne od polityki bezpieczeństwa. Niestety to podejście
ogranicza możliwość przechowania, niektórych obiektów przez węzeł,
gdyż mogą one nie mieć wbudowanej odpowiedniej wtyczki. Wytłumaczenie
powyższej sytuacji wymaga posłużenia się przykładem: Węzeł u chce
umieścić w sieci obiekt klasy A o identyfikatorze A id . Wykonuje operację
insert, która przesyła obiekt poprzez sieć do celu, którego identyfikator
jest najbliższy względem A id . Przyjmijmy, że punktem docelowym będzie
węzeł v. Jeżeli v posiada wtyczkę zawierającą plik A.class, toużywając
deserializacji poprawnie odbierze obiekt A i umieści go w swojej pamięci
trwałej. W przeciwnym razie próba rozpakowania obiektu A nie powiedzie
się i zostanie zgłoszony wyjątek.
• Weryfikacja on-line zakłada, że definicje klas są pobierane w sposób dynamiczny
i uruchomienie obiektów odbywa się w przygotowanym i nadzorowanym
środowisku (np. piaskownicy). To podejście jest znacznie trudniejsze
do zaimplementowania, ale nie nakłada ograniczeń co do możliwości
przechowywania konkretnych obiektów przez określony węzeł. Wrócę do
poprzedniego przykładu. Węzeł u nadal chce przesłać obiekt A do węzła
u. W tym celu u opakowuje A oraz zawartość pliku A.class w jeden
obiekt Content, którego klasa znana jest obu węzłom. Ponadto obiekt Content
implementuje dwie metody put oraz get, które pozwalają „upakować”
przesyłane obiekty w standardowych tablicach bajtów. Gdy Content dotrze
do v ten rozpakuje najpierw plik A.class i wczyta go używając własnego
SecureClassLoader’a, który ustawi ograniczenia dla tego obiektu.
W początkowej implementacji systemu Pastor zostały użyte elementy weryfikacji
off-line oraz on-line. Obiekty w obecnej implementacji Pastora wysyłane
są w specjalnym kontenerze Content, ale bez dołączonej definicji klasy. Definicje
pobierane są z wtyczek, które muszą zostać umieszczone w katalogu plugin/
w pliku jar.
Więcej informacji na temat bezpieczeństwa w Java 2 czytelnik znajdzie w
książce Li Gonga [Gon99].