Bezpieczeństwo w Javie

Nowy model bezpieczeństwa Java zapewnia elastyczną kontrolę dostępu sterowaną przez administratora systemu.

Nowy model bezpieczeństwa Java zapewnia elastyczną kontrolę dostępu sterowaną przez administratora systemu.

Jedną z głównych cech platformy Java, znakomicie predysponującą ją do używania w środowisku sieciowym, są jej mechanizmy bezpieczeństwa. Były one jednak tak rygorystyczne i mało elastyczne, że pytanie, najczęściej zadawane przez programistów, zamierzających skorzystać w palecie z usług np. systemu operacyjnego, brzmiało: "Jak wyłączyć tę właściwość Javy?"

Sun, dostrzegając ten problem, nie tyle usunął ochronę zasobów z aplikacji i apletów Java, co stworzył rozwiązanie architektoniczne bardziej elastyczne, w którym większa odpowiedzialność za bezpieczeństwo systemu spoczywa teraz na programiście i administratorze systemu. Model bezpieczeństwa zmieniał się od sztywnego ograniczenia w JDK 1.0, przez możliwość cyfrowego podpisywania programów w JDK 1.1, do opcji zarządzania bezpieczeństwem w JDK 1.2.

Skrzynia z piaskiem

Java Development Kit 1.0 zawiera podstawowy model bezpieczeństwa systemu komputerowego, pozwalający na bezpieczne wykonywanie kodu niewiarygodnego, o którego właściwościach nic nie wiadomo. Kod każdego apletu musi się wykonywać w tzw. skrzyni z piaskiem (sandbox), co jest analogią do metody niszczenia niebezpiecznych materiałów przez strażaków i saperów. Przeglądarka Web uniemożliwiała apletom wykonywanie wielu działań, w szczególności odczytywanie i zapis plików na dysku lokalnym (lub sieciowym) oraz łączenie się z dowolną lokalizacją Web, poza tą, z której pochodzi aplet.

Problem z tym modelem bezpieczeństwa polega na tym, że autorzy bezpiecznych apletów uważali go za zbyt restrykcyjny. Programista nie mógł np. na dysku lokalnym zapisać niewielkiej informacji o stanie połączenia z serwerem.

Wierzymy ci, jeśli się podpisałeś

W Java Development Kit 1.1 wprowadzono tzw. pliki archiwalne Java (Java Archive - JAR), stanowiące kontenery programów w Javie i ich sygnaturę elektroniczną. Pozwalają one na potwierdzenie tożsamości twórcy/nadawcy pliku (authentication) oraz weryfikację, że nikt po drodze nie zmienił ich zwartości. Jeżeli więc przyjmiemy, że kod podpisany przez wiarygodnych nadawców jest bezpieczny, nawet jeśli dotarł do nas przez mało bezpieczny kanał (Internet), możemy całkowicie usunąć ograniczenia co do wykonywania apletów.

Administrator systemu może zdeklarować, które źródła informacji są bezpieczne. Ma to jednak wadę, gdyż wprowadza metodę ochrony mało elastyczną - typu wszystko lub nic. Podobny model bezpieczeństwa komponentów ActiveX wprowadził również Microsoft, dopuszczając sygnatury elektroniczne w Internecie.

W modelu bezpieczeństwa z JDK 1.1 nie było więc możliwości zdefiniowania apletów pochodzących z "częściowo wiarygodnych źródeł", pozwalając im np. na odczyt danych z dysku lokalnego, ale nie na zapis, lub dopuszczając dostęp tylko do określonych katalogów.

W JDK 1.0 i 1.1 nie istniały API, pozwalające programiście na tworzenie własnego modelu bezpieczeństwa, nie związanego bezpośrednio z używaniem sandboxu.

Szersza skrzynia z piaskiem

JDK 1.2 wprowadza pojęcie rozszerzonej skrzyni z piaskiem (Extended Java Sandbox), która może zawierać część dysku lokalnego. Aplety, pochodzące z nieznanych źródeł, nadal muszą działać w ramach sandboxu, zgodnego z JDK 1.0, natomiast aplety z wiarygodnych źródeł wykonują się w rozszerzonym sandboxie.

Administrator systemu określa zasady dostępu do systemu przez aplety Java w zewnętrznym pliku policy file, definiującym tzw. domeny ochrony, tj. zestaw uprawnień. Zapisuje się w nim szczegółowo prawa dostępu - dopuszczając np. połączenia z określonymi węzłami Web, możliwości odczytu lub zapisu albo odczytu i zapisu do określonych plików i katalogów.

Kontroler dostępu

Gdy kod API zażąda wykonania czynności związanej z przekroczeniem ram standardowego sandboxu, np. odczytania pliku z dysku, specjalny obiekt Java - kontroler dostępu, decyduje o możliwości wykonania tej operacji. W tym celu kontroler dostępu przegląda stos wywołań metod w maszynie wirtualnej Java od góry stosu do dołu. Każda metoda należy do określonej klasy, która ma zdefiniowaną domenę ochrony, każda metoda jest więc związana z określonym zbiorem uprawnień.

Jeżeli podczas przeglądania stosu wywołań metod kontroler dostępu znajdzie metodę, nie mającą żądanych uprawnień - metoda się nie wykona, natomiast zostanie wywołana obsługa wyjątków bezpieczeństwa. Jeżeli natomiast kontroler dojdzie do dna stosu, metoda ma prawo wykonać żądaną operację.

Istnieją również tzw. domeny uprzywilejowane. Metody z nimi związane mogą np. wykonywać operacje na rzecz innych metod. Kontroler dostępu po znalezieniu na stosie metody z domeny uprzywilejowanej nie przegląda już stosu do końca, lecz pozwala na wykonanie operacji. Przykładowo, aplet z niewiarygodnego źródła może potrzebować dostępu do lokalnych plików fontów. Uprzywilejowane domeny i metody z nimi związane umożliwią mu to.

Aplety i aplikacje

Ograniczenia wykonywania w ramach sandboxu dotyczą jedynie apletów Javy, pobieranych z Internetu i firmowego intranetu. Natomiast samodzielne aplikacje w Javie, o dowolnym rozwiązaniu architektonicznym (klient/serwer, wielowarstwowa architektura z serwerami aplikacji), wykonywane na komputerze klienta, nie podlegały dotychczas tym ograniczeniom.

Poczynając od JDK 1.2, wprowadzono możliwość ochrony dostępu do zasobów przez aplikacje napisane w Javie w taki sam sposób, jak w przypadku apletów. Wywołanie aplikacji z odpowiednią opcją, łączącą aplikację z plikiem praw dostępu, pozwala na korzystanie z tych samych mechanizmów ochrony.


TOP 200