S

ystem Linux oferuje różnorodne metody przyznawania uprawnień do plików. Oprócz tradycyjnej, uznaniowej kontroli dostępu (DAC – Discretionary Access Control) obsługuje również listy kontroli dostępu (ACL – Access Control Lists) i obowiązkową kontrolę dostępu (MAC – Mandatory Access Control). Wszystkie te mechanizmy działają na podstawie przyznawania uprawnień, gdy domyślnie nic nie jest dozwolone. To podejście jest również czasami określane jako listy dostępowe (ang. allow list). Analogicznie, jak przy tworzeniu reguł dla zapór sieciowych – blokujemy wszystko i zezwalamy na selektywny ruch. Jednak zarówno DAC i jego rozwinięcie ACL pozwalają na implementację negatywnych uprawnień. Negatyw – występuje tutaj jako pojęcie odwrotności pozytywu – czyli dodawania uprawnień w zupełnie inny sposób niż to przyjęto – odwołując się do poprzedniego przykładu – blokujemy selektywny ruch, ale wszystko inne jest dozwolone. W przypadku dostępu do plików uprawnienia takie uniemożliwiają dostęp określonym użytkownikom lub grupom, gdy wszyscy inni zachowują dostęp. Tego typu praktyka jest raczej rzadkością, za to powszechnie postrzegana jako zła w przypadku uprawnień i ruchu sieciowego.
[ czytaj całość… ]

W

yobraźmy sobie następujący scenariusz. Wyciekł klucz SSH umożliwiający zalogowanie się do zwykłego konta platformy wdrożeniowej. Był on używany do wdrażania i aktualizacji repozytoriów za pomocą ansible. Umożliwia on zalogowanie się na powłokę systemową grupy serwerów, na której są budowane i uruchamiane kontenery Docker. Samo konto nie posiada żadnych dodatkowych uprawnień ani grup. Zastanówmy się teraz w jaki sposób możemy dokonać eskalacji uprawnień wykorzystując jedną z przestrzeni nazw (ang. namespace) kontenera Docker oraz rozszerzonej możliwości Linuksa (ang. capabilities).
[ czytaj całość… ]

W

najnowszym numerze Linux Magazine Tim Schürmann opisał bardzo ciekawy projekt: Firejail – program do tworzenia piaskownic (ang. sandboxes), który redukuje ryzyko naruszenia bezpieczeństwa systemu poprzez ograniczanie środowiska niezaufanych aplikacji za pomocą przestrzeni nazw, seccomp oraz Linux capabilities. Pozwala to procesowi i jego potomnym na posiadanie własnego widoku systemu plików, współdzielonych zasobów jądra, stosu sieciowego, tabeli procesów itd.. Firejail zintegrowany jest z cgroups i dodatkowo może zostać uruchomiony w już działającym środowisku SELinux, czy AppArmor.

Więcej informacji: Firejail HOWTOs

D

o uruchomienia serwera Apache (za przykład posłuży system CentOS 6.x) potrzebne są nam „POSIX capabilities” (pakiet RPM libcap). Szczerze mówiąc sam mechanizm PCAP stanowi obszerny materiał – w tym wpisie zostanie przedstawiony tylko szczątkowo jako możliwość uniknięcia korzystania przez serwer httpd z praw administratora do nasłuchu na porcie 80. Ze względu na przypisywanie uprawnień PCAP plikom w postaci rozszerzonych atrybutów (ang. extended attributes) pierwszym krokiem jest modyfikacja binarnego pliku httpd:
[ czytaj całość… ]