sandbox do wykonania potencjalnie nieprzyjazny kod Pythona

Question

Powiedzmy, że w Internecie istnieje serwer, który można wysłać kawałek kodu do oceny. W pewnym momencie serwer pobiera cały kod, który został przesłany, i zaczyna go uruchamiać i oceniać. Jednak w pewnym momencie na pewno wpadnie na "os.system (" rm -rf * ")" wysłany przez jakiegoś złego programistę. Oprócz "rm -rf" możesz spodziewać się, że ludzie spróbują użyć serwera do wysyłania spamu lub wysyłać komuś, lub wygłupiać się z rzeczami "while True: pass".

Czy istnieje sposób na pogodzenie się z takim nieprzyjaznym/niezaufanym kodem? W szczególności interesuje mnie rozwiązanie dla Pythona. Jeśli jednak masz informacje na temat innych języków, udostępnij je.

Answer 1

Możesz sprawdzić, pysandbox, który właśnie to robi, chociaż trasa VM jest prawdopodobnie bezpieczniejsza, jeśli możesz sobie na to pozwolić.

Answer 2

Możesz wypróbować ogólną usługę Sanbox, taką jak Sydbox lub Gentoo's sandbox. Nie są one specyficzne dla Pythona.

Oba mogą być skonfigurowane do ograniczania odczytu/zapisu do niektórych katalogów. Sydbox może nawet pracować w piaskownicy.

Answer 3

Nie można podać absolutnego rozwiązania, ponieważ definicja "złego" jest trudna do uchwycenia.

Czy otwieranie i zapisywanie do pliku jest złe czy dobre? Co jeśli ten plik to/dev/ram?

Możesz profilować podpisy zachowań lub próbować blokować wszystko, co może być złe, ale nigdy nie wygrasz. JavaScript jest całkiem dobrym tego przykładem, ludzie uruchamiają dowolny dowolny kod javascript na swoich komputerach - powinien być piaskowany, ale pojawiają się różne problemy z zabezpieczeniami i warunki brzegowe.

Nie mówię, nie próbuj, dowiesz się dużo z procesu.

Wiele firm wydało miliony (Intel właśnie wydał miliardy na McAffee) próbując zrozumieć, jak wykryć "zły kod" - i codziennie maszyny z oprogramowaniem antywirusowym McAffe są zarażone wirusami. Kod Pythona nie jest mniej niebezpieczny niż C. Możesz uruchamiać wywołania systemowe, wiązać biblioteki C, itp.

Answer 4

Poważnie rozważałbym wirtualizację środowiska, aby uruchomić te rzeczy, tak aby wykorzystać w dowolnym mechanizmie, który można wdrożyć. firewalled jeszcze raz przez konfigurację maszyny wirtualnej.

Liczba użytkowników i rodzaj kodu, który należy przetestować/uruchomić, miałby znaczny wpływ na wybór z jednej strony. Jeśli nie oczekuje się, że będą się łączyć z plikami lub bazami danych, lub wykonywać zadania wymagające dużej mocy obliczeniowej, a ty masz bardzo niskie ciśnienie, możesz być prawie w porządku, po prostu całkowicie uniemożliwiając dostęp do plików i nakładając limit czasu na proces, zanim zostanie zabity i zgłoszenie zgłoszone jako zbyt kosztowne lub złośliwe.

Jeśli kod, który ma zostać przetestowany, może być dowolnym rozszerzeniem lub stroną Django, prawdopodobnie masz dużo pracy.

Answer 5

Jeśli nie są specyficzne dla realizacji CPython, należy wziąć pod uwagę patrząc na pypy^[wiki] do tych celów - to dialekt Python pozwala kodu przejrzystego podziału na piaskownice.

W przeciwnym razie, można podać fałszywy __builtin__ i __builtins__ w odpowiednich globalnych/mieszkańcami argumentów exec lub eval.

Co więcej, można podać słownikowy obiekt zamiast prawdziwego słownika i prześledzić, co robi niezaufany kod z jego przestrzenią nazw.

Co więcej, można faktycznie śledzić ten kod (wydając sys.settrace() w zamkniętym środowisku przed wykonaniem jakiegokolwiek innego kodu), aby można było przerwać wykonywanie, jeśli coś pójdzie źle.

Jeśli żadne z rozwiązań nie jest akceptowalne, należy użyć piaskownicy na poziomie systemu operacyjnego, takiej jak chroot i standardowy moduł pytlowy multiprocess, aby odrodzić pracownika kodu w oddzielnym zabezpieczonym procesie.

Answer 6

Myślę, że taka poprawka będzie naprawdę trudna i przypomina mi wykład, na którym opowiadałem o zaletach programowania w środowisku wirtualnym. Jeśli robisz to praktycznie fajnie, jeśli to robią. To nie rozwiąże problemu True: pass, ale rm -rf/nie będzie miało znaczenia.

Answer 7

O ile się nie mylę (i bardzo dobrze mogę być), to jest wiele powodów, dla których Google zmienił język Python dla App Engine. Uruchamiasz kod Pythona na swoim serwerze, ale usunięto możliwość zapisywania do plików. Wszystkie dane są zapisywane w bazie danych "nosql".

To nie jest bezpośrednia odpowiedź na twoje pytanie, ale przykład tego, w jaki sposób ten problem został rozwiązany w pewnych okolicznościach.