Najprostszy możliwy bezpieczny piaskownica (wymagane ograniczone zasoby)

Pracuję nad projektem, który implementuje rozproszone symulacje: dowolny kod jest wykonywany na wielu węzłach, a wyniki są później gromadzone i agregowane.

Każdy węzeł jest instancją maszyny wirtualnej Ubuntu Linux i uruchamia proces główny, który dba o przekazanie kodu do wykonania do wielu procesów roboczych (1 dla każdego rdzenia).

To pytanie dotyczy sposobu upewnienia się, że każdy pracownik działa w środowisku piaskownicy bez uciekania się do użycia wystąpienia maszyny wirtualnej dla każdego z nich. Dokładne wymagania dla pracowników to:

• fs : brak uprawnień do zapisu, uprawnienie tylko do odczytu ograniczone do jednego katalogu (i podfolderów)
• net : dozwolona tylko komunikacja lokalna (IPC, TCP, cokolwiek ...)
• mem : ograniczenie wykorzystania pamięci (brak pamięci wymiany) zabij, jeśli przekroczy limit pamięci
• procesor : dozwolony tylko 1 rdzeń, zabij, jeśli z upływem czasu

Nie należy nakładać żadnych innych ograniczeń: pracownik powinien mieć możliwość ładowania bibliotek dynamicznych (z folderu tylko do odczytu), tworzenia nowych wątków lub procesów, wywoływania funkcji systemowej, ecc ecc, ale ograniczenia muszą być dziedziczone przez spawnowane / ładowane jednostki i należy zastosować w sposób sumaryczny (na przykład nie możemy sprawić, by robotnik spawnował dwa wątki, które używają 800 MB każdy to limit pamięci dla takiego pracownika to 1 GB).

Oczywiste jest, że pracownik nie powinien mieć możliwości podniesienia swoich praw.

Sporo czasu poświęciłem na sprawdzenie dostępnych alternatyw (SELinux, AppArmor, cgroups, ulimit, Linux namespaces, LXC, Docker, ...) pod kątem najprostszego rozwiązania, które spełnia moje wymagania, ale moje doświadczenie w tej dziedzinie jest ograniczone.

Obecne zrozumienie: LXC i Docker są trochę ciężkie dla mojego przypadku użycia i nie są całkowicie bezpieczne 1 . AppArmor jest lepszy niż SELinux ze względu na łatwiejszą konfigurację, użyj go do ograniczeń fs i net; cgroups lepiej niż ulimit (który działa na jednym procesie), używał go do ograniczeń mem i cpu.

Czy to najprostszy sposób na osiągnięcie mojego celu? Czy mogę używać wyłącznie AppArmor lub cgroups? Czy w moim modelu jest jakaś dziura w zabezpieczeniach? Wytyczną powinien być „pracownik może sam siebie obalić, ale nic więcej” .

Tak, możesz używać cgroups i SELinux / AppArmor wyłącznie do monitorowania i kontrolowania arbitralności kodu, który wykonasz.

Za pomocą cgroups możesz wykonać następujące czynności:

1. Ogranicz użycie rdzenia procesora do 1 procesora w cpusetpodsystemie
2. Ustaw limity wykorzystania pamięci za pomocą memorypodsystemu, śledząc nawet widelce. Zobacz https://github.com/gsauthof/cgmemtime dla przykładu.
3. Zapobiegaj dostępowi sieciowemu do wszystkiego, co nie jest włączone low net_priopodsystemie.

A dzięki SELinux / AppArmor możesz ograniczyć dostęp do odczytu / zapisu procesu.

Uwaga: nie jestem zaznajomiony z AppArmor, ale jest to system obowiązkowej kontroli dostępu (MAC), co oznacza, że ​​pilnowanie pisania i czytania jest zadaniem.

Korzystanie z tych systemów polega na pisaniu odpowiednich konfiguracji. Oczywiście wszystko to jest o wiele łatwiej powiedzieć niż zrobić. Oto kilka linków referencyjnych na początek:

• Przewodnik zarządzania zasobami RedHat
• Wiki CGroup ArchLinux

Powodzenia!

Odrzuciłbym SELinux dla AppArmor tylko gdybym używał Ubuntu . (naprawdę dość trudne)

LXC nie jest samo w sobie bezpieczny Jeśli potrzebujesz bezpieczeństwa, musisz użyć ich poprzez libvirt (oparty na SELinux MLS ).

Twój problem jest nieskończony, więc nie próbuj znaleźć żadnego rozwiązania z półki i bez nieskończonego czasu, pamiętaj, że nawet kernel.org zostało pwonione, a ostatnio FBI oświadczyło, że ktoś używa ich systemów od lat, dopóki nie został wykryty.

Pójdę z LXC / libvirt dla całkiem dobrego bezpieczeństwa lub spróbuję „nowych” przezroczystych pojemników Intel , które używają bardzo lekkiej VM do twojego pojemnika z wyraźnym użyciem DAX / KSM (nie testowałem ich, ale wyglądają bardzo dobrze rzeczywiście obiecujące).

Jeśli martwisz się wykorzystaniem jądra, grsecurity jest twoim rozwiązaniem, ale musisz zintegrować go z rozwiązaniem kontenerowym (z pewnością bóle głowy).

Na pewno nie jest to łatwe zadanie, LXC / libvirt są naprawdę schludne, ale może najlepszym rozwiązaniem są przezroczyste pojemniki.

Doker? Nie używam / nie chciałbym używać dokera do więcej niż testów lokalnych, gdy nie było dostępnego wagonu, potrzebują dużo więcej pracy i lepszej społeczności.

Oczywiście pojemniki systemowe też są fajne, ale zakładam, że ich nie lubisz, bo nawet o nich nie wspomniałeś i nie są one rozwiązaniem niezależnym od dostawcy.

Jeśli chcesz czegoś „łatwiejszego” i bardziej amatorskiego, mógłbyś sprawdzić Firejail , korzystałem z niego w niektórych „aplikacjach” na komputery i spełnia on swoje zadanie (dość łatwo jest stworzyć szablon dla niestandardowej aplikacji, użyć „prywatnego” montuje się na wierzchu twoich katalogów i ogranicza sieć tylko do użytku lokalnego, odradzane procesy dziedziczą po rodzicu i kontynuują ...).

Pozdrawiam i baw się dobrze, nie wariując. ;)

seccomp-bpf to kolejna opcja, która działa dobrze dla OpenSSH, vsftpd i Chromium, ma tylko exit (), sigreturn (), read (), używa także write (), chociaż umożliwia filtrowanie wywołań systemowych przy użyciu konfigurowalnych reguł filtrowania pakietów Berkeley. Może być również używany w połączeniu z cgroups dla pamięci, procesora itp.

https://wiki.mozilla.org/Security/Sandbox/Seccomp

Możesz przyjrzeć się systemom gridowym. W szczególności BOINC ( http://boinc.berkeley.edu ) sprawdza prawie wszystkie twoje skrzynki.

Wierzę, że działa on na twoje parametry jako takie:

fs: może czytać / zapisywać do własnego katalogu, nigdzie indziej

net: można skonfigurować tak, aby zezwalał na dostęp sieciowy tylko do twojego serwera BOINC, ale nie jest domyślny po wyjęciu z pudełka IIRC

mem: tak, oddzielne limity pamięci dla maszyn bezczynnych i nieużywanych

procesor: tak, może nawet powiedzieć „nie uruchamiaj, jeśli komputer nie jest bezczynny”