Jakie języki inne niż Java mają modele zabezpieczeń dla kodów nieuprzywilejowanych lub uprzywilejowanych?

Question

Niedawno dowiedziałem się o modelu bezpieczeństwa Java. Większość ludzi uważa, że ​​Java jest bezpieczna, ponieważ jest odporna na przepełnienie bufora, itp., Ale istnieje cały ten model bezpieczeństwa Java skupiony wokół sprawdzania, czy kod ma uprawnienia do wykonywania określonych czynności. Naprawdę rozwiązują trudny problem: jak uruchomić dowolny niezaufany kod (powiedzmy w przeglądarce internetowej), ale uniemożliwić mu dostęp do bazowego systemu w złośliwy sposób, zachowując jednocześnie możliwość interakcji z systemem.

Piaskownica C++ lub coś podobnego byłaby bardzo trudna do podjęcia, ponieważ język nakazuje wykonywanie arytmetyki wskaźników itp., Umożliwiając złośliwemu kodowi uszkodzenie innych części procesu. Ponieważ istnieje wiele języków bezpiecznych pamięci, zastanawiałem się jednak, jakie inne języki mają wyrafinowane modele zabezpieczeń i jak się je porównuje do języka Java.

Nie wiem od ręki, jak wiele języków starają się mieć pojęcia takie jak "piaskownica", itp. Szukam wskazówek, aby dowiedzieć się o tym interesującym kierunku bezpieczeństwa komputerowego.

Answer 1

Perl ma naprawdę fajną funkcję zwaną trybem taint (-T). Po włączeniu tego trybu każda zmienna pochodząca ze świata zewnętrznego (env vars, dane GET/POST itp.) Jest skażona, a każda zmienna dotykająca zmienionej zapory jest również skażona. Zmienione zmienne nie mogą być używane w metodach dotykających świata zewnętrznego (SQL, exec/system, itp.). Jedynym sposobem odznaczenia zmiennej jest zrobienie regexu; wszystkie dopasowane grupy są nieskażone. Oczywiście możesz obejść tryb taint, wykonując wyrażenie regularne dla /(.*)/, ale chodzi o to, że musisz aktywnie napisać taki zły kod - zamiast tylko beztrosko zapomnieć o odkażaniu danych wejściowych - jeśli masz zamiar zrobić coś głupiego, jak konkludowanie danych wprowadzanych przez użytkownika bezpośrednio do MySQL.

Answer 2

Model E programming language oparty jest na capability security model, w którym dostęp do obiektów, ewentualnie dystrybuowanych w różnych systemach, jest możliwy tylko poprzez jawne "możliwości", którymi musi zarządzać program. Jedyne przywileje, jakie daje kod, to prawa przekazywane za pośrednictwem możliwości przez "twórcę", gdy jest on tworzony. Chodzi o to, aby powerbox shell przyznawać przywileje fragmentom kodu podczas ich wykonywania.

Co to trochę zaskakujące jest to, że jest podobny do Erlangwspółbieżności prymitywów - zdolność do kontaktu proces Erlang wymaga znajomości PID procesu - co oznacza inny proces nadanie przywileju przez komunikacji pid. (Oczywiście, Erlang również ma registered processes, który można nazwać po imieniu. I, Erlang również używa simple cookie scheme do zdalnego dostępu do systemu, a dostęp do wykonywania podstawowych poleceń IO plik na zdalnych węzłach nie są zablokowane. Erlang minus kilka funkcji może z łatwością być niesamowitym środowiskiem wykonawczym w piaskownicy, ale nie mam pojęcia, ile pracy wymagałoby usunięcie tych funkcji.)

, podobna do Perl's Taint environment as described by yshavit.

Czy mogę zaufać któregoś z tych systemów wyłącznie w celu wykonania potencjalnie złośliwego kodu? Prawdopodobnie nie.

Istnieją środowiska zaprojektowane przez codepad.org w celu ograniczenia wykonywania niezaufanego kodu przy użyciu active debugging facilities. Te też są przydatne, ale nie jestem pewien, jak daleko ufałbym jemu także.Ufam, że coś bardziej jak QEMU+KVM/VMWare/Xen więcej lub OpenVZ/vServers albo mandatory access control narzędzia takie jak AppArmor, SELinux, TOMOYO lub SMACK. (Pracuję nad AppArmor od ponad dekady, więc jestem nieco stronniczy w tym, jako rozwiązanie dla wielu osób. Pozostałe to dobre narzędzia, które mają więcej sensu dla różnych wdrożeń.)