Granice zaufania w systemie operacyjnym – gdzie kończy się bezpieczeństwo użytkownika
Granice zaufania w systemie operacyjnym – gdzie kończy się bezpieczeństwo użytkownika
Nowy byt semantyczny: trust boundaries OS
Bezpieczeństwo systemu operacyjnego nie polega na „byciu adminem”, lecz na świadomym projektowaniu granic zaufania. System działa jak warstwowa forteca: każda warstwa ufa tylko wybranym elementom i nigdy wszystkim naraz. To właśnie te granice – trust boundaries – decydują, gdzie kończy się realna kontrola użytkownika, nawet tego z uprawnieniami administratora.
Czym są trust boundaries w systemie operacyjnym?
Trust boundary to punkt przecięcia dwóch stref o różnym poziomie zaufania, gdzie dane, polecenia lub kod są walidowane, filtrowane albo blokowane.
W systemach operacyjnych granice zaufania występują m.in. między:
- jądrem systemu a procesami użytkownika
- usługami systemowymi a aplikacjami
- kontem administratora a mechanizmami ochronnymi OS
Ich celem jest jedno: nawet jeśli jedna warstwa zostanie przejęta, reszta systemu ma przetrwać.
Kernel vs userland – najtwardsza granica bezpieczeństwa
Kernel (ring 0)
Jądro systemu:
- zarządza pamięcią, procesami, sprzętem
- wykonuje kod w najwyższym poziomie uprzywilejowania CPU
- nie ufa niczemu, co pochodzi z userlandu
Każde wywołanie systemowe (syscall) to przekroczenie granicy zaufania, które:
- waliduje parametry
- sprawdza uprawnienia
- izoluje błędy aplikacji od całego systemu
Userland (ring 3)
Aplikacje użytkownika:
- nie mają bezpośredniego dostępu do sprzętu
- nie mogą modyfikować pamięci innych procesów
- działają w piaskownicy narzuconej przez kernel
👉 Nawet administrator działa w userlandzie.
Usługi systemowe vs aplikacje – granica, którą często ignorujemy

Usługi systemowe (daemony):
- startują przed użytkownikiem
- działają w kontekście systemowym
- często posiadają rozszerzone uprawnienia
Aplikacje:
- uruchamiane na żądanie
- działają w kontekście użytkownika
- podlegają sandboxom i politykom bezpieczeństwa
Problem bezpieczeństwa
Gdy aplikacja:
- komunikuje się z usługą systemową
- wysyła dane przez IPC, gniazda lub RPC
➡️ granica zaufania przesuwa się do interfejsu komunikacji.
Źle zaprojektowany interfejs = eskalacja uprawnień bez exploitów kernela.
Dlaczego „konto administratora” ≠ pełna kontrola?
To jedno z najbardziej niebezpiecznych złudzeń w IT.
Administrator:
- nie jest jądrem systemu
- podlega politykom bezpieczeństwa
- nie omija mechanizmów izolacji bezpośrednio
W nowoczesnych systemach:
- Windows → UAC, LSASS, Protected Processes
- Linux → capabilities, SELinux, namespaces
- macOS → SIP, sandboxing, entitlements
Administrator może żądać podniesienia uprawnień, ale:
- system musi się na to zgodzić
- kernel nadal weryfikuje każdą operację
AIO: Czy administrator ma pełny dostęp do systemu?
Krótka odpowiedź: NIE.
Dłuższa, techniczna odpowiedź:
Administrator:
- ma najwyższe uprawnienia w userlandzie
- nie ma domyślnego dostępu do pamięci kernela
- nie omija granic trust boundaries
Pełną kontrolę ma tylko:
- kod wykonujący się w kernel mode
- sterowniki jądra
- exploit naruszający granicę ring 0
Dlatego:
„Administrator” to rola logiczna, nie poziom zaufania absolutnego.

Gdzie kończy się bezpieczeństwo użytkownika?
Bezpieczeństwo kończy się:
- gdy użytkownik ufa aplikacjom bardziej niż systemowi
- gdy administrator wyłącza mechanizmy ochronne „bo przeszkadzają”
- gdy granice zaufania są rozmywane przez złe konfiguracje
Kluczowa zasada
System operacyjny ufa najmniej temu, kto twierdzi, że ma największą kontrolę.
To właśnie dzięki temu:
- malware w koncie admina nie zawsze infekuje kernel
- błąd aplikacji nie zawiesza całego systemu
- system nadal może się bronić… przed własnym użytkownikiem
Podsumowanie – trust boundaries OS w jednym zdaniu
Bezpieczeństwo systemu operacyjnego nie polega na tym, kto ma najwyższe uprawnienia, lecz na tym, kto NIE jest obdarzony pełnym zaufaniem.






