W tamtym czasie w dostępnych publikacjach Capsicum było porównywane do (między innymi) SELinux i seccomp, jako potencjalnie równoważnych technologii w systemie Linux. Seccomp należy do mniej znany rozwiązań, co wynika z jego mniejszych możliwości. Wygląda jednak na to, że w najbliższym czasie ma się to zmienić.
Parę dni temu ukazała się nowa wersja jądra Linux 3.5. Jedną z nowości jest "Seccomp-based system call filtering", czyli rozszerzenie mało używanego mechanizmu seccomp.
Seccomp powstał w 2005 i początkowo miał ograniczać wywoływanie systemowych funkcji przez programy użytkowników do czterech podstawowych: read(), write(), exit() i sigreturn(). W późniejszym czasie Google zadeklarował implementacje swojej przeglądarki Chrome dla systemu Linux. W poszukiwaniu mechanizmów, które mogłyby pozwolić na tworzenie mechanizmów sandbox w przeglądarce Chrome na platformie Linux Google zainteresował się seccomp. Jednak wtedy był on zbyt prymitywny i trochę nadrabiano to przy pomocy SELinux. Nie znaczy to jednak, że Google zrezygnował z seccomp. Rozszerzyli jego funkcjonalność dodając tzw. "mode 2", który pozwalał definiować listę funkcji systemowych, których nie wolno było wywoływać dla procesu.
Nie było to jeszcze zadowalające rozwiązanie, bo o ile jądro kontrolowało operacji procesu np. zapisywanie do pliku, to nie miało żadnej kontroli nad tym do jakiego pliku program mógł zapisywać. Czyli nie kontrolowało kontekstu operacji, oczywiście poza innymi mechanizmami takimi jak prawa do plików.
Tak więc mechanizmem rozwiązującym ten problem jest nowo dodany mechanizm seccomp z filtrami. Powstała koncepcja aby mechanizm seccomp rozszerzyć o możliwość definiowania filtrów, jak w zaporze ogniowej, z tą różnicą że ta dotyczy dostępu do funkcji systemowych a nie socket-ów. Porównanie trafne, bo do implementacji użyto już istniejący i dopracowany pod katem optymalizacji mechanizm filtrowania pakietów BPF (Berkeley Packet Filter).
Teraz seccomp może kontrolować nie tylko typ operacji ale i ich zakres, np. pozwalać na zapis tylko wtedy gdy celem jest standardowe wyjście "sys_write: (fd == 1)". Projekt Chrome zaimplementował już mechanizm snadbox przy użyciu nowej biblioteki libseccomp. Obecnie znane projekty, które już wdrożyły nowe rozwiązanie to vsftpd 3.0.0 oraz OpenSSH 6.0. 17 lipca o implementacji seccomp filtering w swoim projekcie poinformował również deweloper projektu systemd.
Pisząc o seccomp ciągle używa się stwierdzenia "sandbox". Jednak w oficjalnej dokumentacji w prost jest powiedziane, że mechanizm filtrowania funkcji systemowych to nie sandbox. Tak samo sprawa ma się do porównywania z Capsicum i SELinux. Jeżeli chodzi o ten pierwszy to porównanie jest jak najbardziej prawidłowe, ponieważ oba mechanizmy są używane przez programistów w kodzie programu. Ale Capsicum tworzy swego rodzaju hermetyczne środowisko, a seccomp jest filtrem funkcji systemowych. Efekt jest tylko podobny. SELinux z kolei jest bardziej szerszym rozwiązaniem, dotyczy całego systemu i co najważniejsze jest używanym docelowo przez administratorów. Można go użyć nawet do programów, które nie maja zaimplementowanych żadnych mechanizmów obronnych, albo ograniczyć je jeszcze bardziej tylko do funkcjonalności, z której rzeczywiście korzystamy. W przypadku gdy administrator nie korzysta z SELinux najważniejsze procesy starają bronić się same przez zaprogramowane w nich ograniczenia. Jak widać ma to sens i zysk "ekonomiczny".
Seccomp jest kolejnym mechanizmem zwiększającym szczelność siatki ochronnej oferowanej przez system Linux dla uruchamianych programów.
Więcej informacji:
http://lwn.net/Articles/475043/
http://outflux.net/teach-seccomp/
http://lwn.net/Articles/441232/
http://lwn.net/Articles/332974/
Pisząc o seccomp ciągle używa się stwierdzenia "sandbox". Jednak w oficjalnej dokumentacji w prost jest powiedziane, że mechanizm filtrowania funkcji systemowych to nie sandbox. Tak samo sprawa ma się do porównywania z Capsicum i SELinux. Jeżeli chodzi o ten pierwszy to porównanie jest jak najbardziej prawidłowe, ponieważ oba mechanizmy są używane przez programistów w kodzie programu. Ale Capsicum tworzy swego rodzaju hermetyczne środowisko, a seccomp jest filtrem funkcji systemowych. Efekt jest tylko podobny. SELinux z kolei jest bardziej szerszym rozwiązaniem, dotyczy całego systemu i co najważniejsze jest używanym docelowo przez administratorów. Można go użyć nawet do programów, które nie maja zaimplementowanych żadnych mechanizmów obronnych, albo ograniczyć je jeszcze bardziej tylko do funkcjonalności, z której rzeczywiście korzystamy. W przypadku gdy administrator nie korzysta z SELinux najważniejsze procesy starają bronić się same przez zaprogramowane w nich ograniczenia. Jak widać ma to sens i zysk "ekonomiczny".
Seccomp jest kolejnym mechanizmem zwiększającym szczelność siatki ochronnej oferowanej przez system Linux dla uruchamianych programów.
Więcej informacji:
http://lwn.net/Articles/475043/
http://outflux.net/teach-seccomp/
http://lwn.net/Articles/441232/
http://lwn.net/Articles/332974/