Kontrola dostępu do zasobów w Javie
2009-05-06 00:30
Nadeszła pora na kontynuację poprzedniego testu bezpieczeństwa systemu względem apletów uruchamianych w przeglądarce (oraz aplikacji uruchamianych lokalnie z włączonym menedżerem bezpieczeństwa). Poprzednio pokazałem, jak poprzez prosty wpis można udostępnić wszystko wszystkim lub dodając źródło kodu - tylko apletom z wybranej lokalizacji. To były jednak najprostsze możliwości. Pokażę teraz, że można kontrolować znacznie więcej, na dużo bardziej szczegółowym poziomie. Do testów posłuży ten sam aplet. Osadziłem go poniżej, aby wystarczyło odświeżać tę stronę badając w ten sposób zmiany w jego zachowaniu.
Jeżeli ktoś zmieniał ustawienia polisy, to na początek przywróćmy początkową postać, poprzez usunięcie sekcji grant dla źródła kodu: "http://zgibek.com/blogger/". Szczegóły dotyczące pliku z polisą są w poprzednim poście. Tym razem dodam jednak, że o ile plik dostarczany z javą jest dobrym miejscem startowym i warto go przejrzeć, to wcale nie musimy go szukać i modyfikować. Zresztą czasem możemy nie mieć do niego dostępu lub praw do jego modyfikacji. Zgodnie z dokumentem opisującym "Default Policy File Locations" prościej jest utworzyć sobie w swoim katalogu domowym plik o nazwie .java.policy (uwaga na kropkę z przodu oznaczającą plik ukryty w systemach *nix). I od tej pory to w nim dokonywać swoich modyfikacji. Dużo prościej i czytelniej
Startując z domyślną konfiguracją bezpieczeństwa powinniśmy w powyższym aplecie dostać informację o niepowodzeniu:
tworzę plik...
Nie udało się dostać do pliku: ./test.file
java.security.AccessControlException: access denied (java.io.FilePermission ./test.file write)
Zatem zaczynamy! Na początek dodajmy uprawnienie, którego brak jest zgłaszany w wyjątku. Aby to zrobić potrzebujemy zmodyfikować plik z polisą - dodajmy cały wpis grant, dla źródła kodu zawierającego ten skompilowany aplet:
grant codebase "http://zgibek.com/blogger/" {
permission java.io.FilePermission "<>", "write";
};
Wpis umożliwi założenie pliku. Czy jednak na pewno? Przeładujmy stronę z apletem... I jak? lepiej?
tworzę plik...
Utworzono plik: Nie udało się dostać do pliku: ./test.file
java.security.AccessControlException: access denied (java.util.PropertyPermission user.dir read)
Okazuje się, że może i udałoby się założyć plik, ale domyślna konfiguracja nie potrafi odczytać bieżącej ścieżki (ściślej - nie ma dostępu do takiego property). Dodajmy zatem też i to uprawnienie:
permission java.util.PropertyPermission "user.dir", "read";
i ponownie przeładujmy stronę. Powinno być lepiej, a jak jest?
tworzę plik...
Utworzono plik: /home/zgibek/./test.file
usuwam plik...
Nie udało się dostać do pliku: ./test.file
java.security.AccessControlException: access denied (java.io.FilePermission ./test.file delete)
Dużo lepiej - zgodnie z uprawnieniami apletowi udało się ustalić katalog oraz utworzyć plik. Napotkał jednak na problem z jego usunięciem. Dodajmy do wcześniejszego uprawnienia zapisu dodatkowe - usunięcie:
permission java.io.FilePermission "<>", "write,delete";
Jaki efekt? Świetny:
tworzę plik...
Utworzono plik: /home/zgibek/./test.file
usuwam plik...
Plik usunięty
Oczywiście, gdyby aplet chciał jeszcze czytać pliki, to potrzebowalibyśmy wyszczególnić operację odczytu. Analogicznie z innymi zezwoleniami. Zaletą jest możliwość dowolnego sterowania co wolno, a czego nie. Dla uproszczenia proponowane uprawnienie umożliwiało nadanie praw dla wszystkich plików. Ale przecież mogłem podać jeden plik lub katalog - np. danych tymczasowych, a dla katalogu np. dokumentów - tylko do odczytu. Im bardziej ograniczymy wolność programów tym więcej swobody będziemy mieć sami - zamiast szukać dziury w całym lub naprawiać system będziemy mogli poświęcić czas innym zainteresowaniom. Jeszcze tylko dla porządku - tak wygląda cały grant (jeżeli utworzyliśmy nowy plik w swoim domowym katalogu, to będzie to jednocześnie cała jego zawartość):
grant codebase "http://zgibek.com/blogger/" {
permission java.io.FilePermission "<>", "write,delete";
permission java.util.PropertyPermission "user.dir", "read";
};
Chętnych poszerzenia swojej wiedzy o możliwych zezwoleniach zapraszam do materiałów źródłowych, czyli "Permissions in JDK". A więcej informacji o plikach zezwoleń: "Default Policy Implementation and Policy File Syntax"
Jeżeli ktoś zmieniał ustawienia polisy, to na początek przywróćmy początkową postać, poprzez usunięcie sekcji grant dla źródła kodu: "http://zgibek.com/blogger/". Szczegóły dotyczące pliku z polisą są w poprzednim poście. Tym razem dodam jednak, że o ile plik dostarczany z javą jest dobrym miejscem startowym i warto go przejrzeć, to wcale nie musimy go szukać i modyfikować. Zresztą czasem możemy nie mieć do niego dostępu lub praw do jego modyfikacji. Zgodnie z dokumentem opisującym "Default Policy File Locations" prościej jest utworzyć sobie w swoim katalogu domowym plik o nazwie .java.policy (uwaga na kropkę z przodu oznaczającą plik ukryty w systemach *nix). I od tej pory to w nim dokonywać swoich modyfikacji. Dużo prościej i czytelniej
Startując z domyślną konfiguracją bezpieczeństwa powinniśmy w powyższym aplecie dostać informację o niepowodzeniu:tworzę plik...
Nie udało się dostać do pliku: ./test.file
java.security.AccessControlException: access denied (java.io.FilePermission ./test.file write)
Zatem zaczynamy! Na początek dodajmy uprawnienie, którego brak jest zgłaszany w wyjątku. Aby to zrobić potrzebujemy zmodyfikować plik z polisą - dodajmy cały wpis grant, dla źródła kodu zawierającego ten skompilowany aplet:
grant codebase "http://zgibek.com/blogger/" {
permission java.io.FilePermission "<
};
Przeładujmy stronę z apletem... I jak? lepiej?tworzę plik...
Utworzono plik: Nie udało się dostać do pliku: ./test.file
java.security.AccessControlException: access denied (java.util.PropertyPermission user.dir read)
Okazuje się, że może i udałoby się założyć plik, ale domyślna konfiguracja nie potrafi odczytać bieżącej ścieżki (ściślej - nie ma dostępu do takiego property). Dodajmy zatem też i to uprawnienie:
permission java.util.PropertyPermission "user.dir", "read";
i ponownie przeładujmy stronę. Powinno być lepiej, a jak jest?
tworzę plik...
Utworzono plik: /home/zgibek/./test.file
usuwam plik...
Nie udało się dostać do pliku: ./test.file
java.security.AccessControlException: access denied (java.io.FilePermission ./test.file delete)
Dużo lepiej - zgodnie z uprawnieniami apletowi udało się ustalić katalog oraz utworzyć plik. Napotkał jednak na problem z jego usunięciem. Dodajmy do wcześniejszego uprawnienia zapisu dodatkowe - usunięcie:
permission java.io.FilePermission "<
tworzę plik...
Utworzono plik: /home/zgibek/./test.file
usuwam plik...
Plik usunięty
Oczywiście, gdyby aplet chciał jeszcze czytać pliki, to potrzebowalibyśmy wyszczególnić operację odczytu. Analogicznie z innymi zezwoleniami. Zaletą jest możliwość dowolnego sterowania co wolno, a czego nie. Dla uproszczenia proponowane uprawnienie umożliwiało nadanie praw dla wszystkich plików. Ale przecież mogłem podać jeden plik lub katalog - np. danych tymczasowych, a dla katalogu np. dokumentów - tylko do odczytu. Im bardziej ograniczymy wolność programów tym więcej swobody będziemy mieć sami - zamiast szukać dziury w całym lub naprawiać system będziemy mogli poświęcić czas innym zainteresowaniom. Jeszcze tylko dla porządku - tak wygląda cały grant (jeżeli utworzyliśmy nowy plik w swoim domowym katalogu, to będzie to jednocześnie cała jego zawartość):
grant codebase "http://zgibek.com/blogger/" {
permission java.io.FilePermission "<
permission java.util.PropertyPermission "user.dir", "read";
};
blog comments powered by Disqus