Bezpieczeństwo przy użyciu skryptów Java (JRuby, Jython, Groovy, BeanShell, itp.)

Question

Czekam na uruchomienie kilku niezrealizowanych skryptów (napisanych w języku, który dopiero zostanie określony, ale musi być oparty na języku Java, więc JRuby, Groovy, Jython, BeanShell itd. są kandydatami). Chcę, aby te skrypty były w stanie robić pewne rzeczy i ograniczać się do robienia innych rzeczy.

Zwykle po prostu skorzystam z JavaManager SecurityManager i skończę z tym. To całkiem proste i pozwala mi ograniczyć dostęp do plików i sieci, możliwość wyłączenia JVM itp. I to będzie działać dobrze na rzeczach wysokiego poziomu, które chcę zablokować.

Ale jest kilka rzeczy, na które chcę zezwolić, ale tylko za pośrednictwem mojego niestandardowego interfejsu API/biblioteki, który udostępniam. Na przykład, nie chcę zezwalać na bezpośredni dostęp do sieci, aby otworzyć URLConnection na yahoo.com, ale jestem OK, jeśli odbywa się to za pomocą MyURLConnection. To znaczy - istnieje zestaw metod/klas, na które chcę zezwolić, a następnie wszystko, co chcę, być poza zasięgiem.

Nie wierzę, że tego rodzaju zabezpieczenia można wykonać za pomocą standardowego modelu zabezpieczeń Java, ale być może tak. Nie mam konkretnego wymagania odnośnie wydajności lub elastyczności w samym języku skryptowym (skrypty będą prostymi wywołaniami proceduralnymi do mojego API z podstawową obsługą pętli/rozgałęzień). Więc nawet "duże" obciążenie, które sprawdza kontrolę bezpieczeństwa przy każdym odbiciu, jest w porządku.

Sugestie?

Answer 1

Zastrzeżenie: Nie jestem ekspertem od interfejsów API Java Security, więc może być lepszy sposób na zrobienie tego.

Pracuję dla Alfresco, opartego na języku Java Open Source Enterprise CMS i zaimplementowaliśmy coś podobnego do tego, co opisujesz. Chcieliśmy zezwolić na pisanie skryptów, ale tylko po to, aby udostępnić mechanizm skryptowy w podzbiorze naszych interfejsów API języka Java.

Wybraliśmy silnik Rhino dla skryptów JavaScript. Pozwala kontrolować, które API są narażone na JavaScript, co pozwala nam wybrać, które klasy są dostępne, a które nie. Koszt, według naszych inżynierów, jest rzędu 10% - nie jest tak źle.

Oprócz tego, i może to być istotne również dla ciebie, po stronie Java używamy Acegi (obecnie Spring Security) i używamy AOP, aby zapewnić kontrolę opartą na rolach, które metody może wywołać dany użytkownik . Działa to całkiem dobrze w przypadku autoryzacji. W efekcie, użytkownik uzyskujący dostęp do naszej aplikacji za pośrednictwem JavaScript ma najpierw dostęp do ograniczonego API, a następnie ten interfejs API może zostać ograniczony nawet w oparciu o autoryzację. Więc możesz użyć technik AOP do dalszego ograniczenia, które metody można wywołać, co pozwala na ujawnienie tego w innych językach skryptowych, takich jak Groovy, itp. Jesteśmy również w trakcie dodawania tych, mając pewność, że nasza bazowa Java Interfejsy API chronią użytkowników przed nieautoryzowanym dostępem.

Answer 2

Możliwe, że będziesz mógł skorzystać z niestandardowego programu ładującego klasy, który nie ma weterynarza łączącego się z klasami przed przekazaniem uprawnień do rodzica.

Można tworzyć własne uprawnienia, sprawdzać te w interfejsach API, które są wrażliwe na bezpieczeństwo, a następnie użyć AccessController.doPrivileged, aby przywrócić odpowiednie uprawnienia podczas wywoływania podstawowego interfejsu API.

Musisz się upewnić, że sam silnik skryptowy jest bezpieczny. Wersja Rhino in the Sun JDK powinna być w porządku, ale bez gwarancji. Oczywiście musisz się upewnić, że wszystko, co jest dostępne dla skryptu, jest bezpieczne.

Answer 3

W Groovy możesz zrobić dokładnie to, o czym wspomniałeś. W rzeczywistości bardzo łatwe. Możesz łatwo ograniczyć uprawnienia niezaufanych skryptów działających w zaufanym środowisku, zezwalać na używanie własnego API, co z kolei może robić rzeczy niezaufane.

http://www.chrismoos.com/2010/03/24/groovy-scripts-and-jvm-security/