Niedawno autorzy standardowej biblioteki C Cosmopolitan i platformy Redbean ogłosili implementację mechanizmu izolacji pledge() dla systemu Linux.
Pierwotnie opracowany przez projekt OpenBSD , pledge pozwala selektywnie blokować aplikacjom dostęp do nieużywanych wywołań systemowych (tworząc białą listę wywołań systemowych dla aplikacji i blokując inne). W przeciwieństwie do mechanizmów kontroli dostępu do wywołań systemowych dostępnych w systemie Linux, takich jak seccomp, pledge został zaprojektowany od podstaw tak, aby był jak najbardziej przyjazny dla użytkownika.
Nieudana inicjatywa izolowania aplikacji w podstawowym środowisku OpenBSD przy użyciu mechanizmu systrace pokazała, że izolacja na poziomie poszczególnych wywołań systemowych jest zbyt skomplikowana i czasochłonna.
Alternatywnie zaproponowano metodę pledge, która umożliwiała tworzenie reguł izolacji bez wchodzenia w szczegóły i manipulowania przygotowanymi klasami dostępu.
Na przykład oferowane klasy to stdio (wejście/wyjście), rpath (pliki tylko do odczytu), wpath (zapis plików), cpath (tworzenie plików), tmppath (praca z plikami tymczasowymi), inet (sieć gniazd), unix (gniazda unix ), dns (rozdzielczość DNS), getpw (dostęp do odczytu bazy danych użytkowników), ioctl (wywołanie ioctl), proc (kontrola procesu), exec (procesy startowe) i id (kontrola uprawnień).
Zasady pracy z wywołaniami systemowymi są określone w formie adnotacji, które zawierają listę dozwolonych klas wywołań systemowych oraz tablicę ścieżek do plików, do których dostęp jest dozwolony. Po skompilowaniu i uruchomieniu zmodyfikowanej aplikacji, jądro przejmuje zadanie monitorowania zgodności z określonymi zasadami.
Osobno rozwijana jest implementacja zastawu dla FreeBSD, która wyróżnia się możliwością izolowania aplikacji bez wprowadzania zmian w ich kodzie, natomiast w OpenBSD wywołanie zastawu ma na celu ścisłą integrację ze środowiskiem bazowym i dodanie adnotacji do kodu każdego z nich.
Przyrzeczenie jest jak zakazany owoc, którego wszyscy pożądamy, gdy szef mówi, że powinniśmy używać rzeczy takich jak Linux. Dlaczego to ma znaczenie? Dzieje się tak dlatego, że pledge() faktycznie sprawia, że bezpieczeństwo jest zrozumiałe. Linux nigdy tak naprawdę nie miał warstwy bezpieczeństwa, którą mogą zrozumieć zwykli śmiertelnicy.
Twórcy portu Linux Pledge poszli w ślady FreeBSD i zamiast wprowadzać zmiany w kodzie, przygotowali dodatkowe narzędzie z pledge.com, które pozwala nakładać ograniczenia bez modyfikowania kodu aplikacji. Na przykład, aby uruchomić narzędzie curl z dostępem tylko do klas wywołań systemowych stdio, rpath, inet i threadstdio, wystarczy uruchomić polecenie `./pledge.com -p 'stdio rpath inet thread' curl http://example.com`.
Narzędzie działa we wszystkich dystrybucjach Linuksa od RHEL6 i nie wymaga uprawnień administratora. Dodatkowo, oparte na bibliotece Cosmopolitan, API umożliwia zarządzanie ograniczeniami w kodzie programów C, umożliwiając między innymi tworzenie enklaw selektywnie ograniczających dostęp do określonych funkcji aplikacji.
W przeszłości kilku programistów próbowało tego. Nie będę wymieniał nazwisk, ponieważ większość z tych projektów nigdy nie została ukończona. Jeśli chodzi o SECOMP, samouczki online wyjaśniają tylko, jak umieszczać wywołania systemowe na białej liście, więc większość ludzi traci zainteresowanie przed wymyśleniem sposobu filtrowania argumentów. Projekty, które posunęły się do przodu, również miały niedopatrzenia, takie jak zezwalanie na zmianę bitów setuid/setgid/sticky. Dlatego nie należy stosować żadnej z obecnych alternatyw. Myślę, że ten wysiłek znacznie przybliża nas do posiadania funkcji pledge() niż kiedykolwiek wcześniej.
Implementacja nie wymaga zmian jądra: ograniczenia dotyczące użyteczności są tłumaczone na reguły SECOMP BPF i przetwarzane przy użyciu natywnego mechanizmu izolacji wywołań systemowych systemu Linux. Na przykład wywołanie obietnicy("stdio rpath", 0) spowoduje konwersję do filtra BPF
A jeśli chcesz dowiedzieć się więcej, szczegóły znajdziesz pod poniższym linkiem.