Izolacja procesów w praktyce – dlaczego aplikacje nadal mogą sobie szkodzić
System operacyjny deklaruje: „każdy proces jest odizolowany”.
Praktyka pokazuje coś innego: procesy są izolowane tylko tam, gdzie system uzna to za konieczne. Reszta to współdzielenie pod ścisłą kontrolą – i właśnie tam zaczynają się problemy.
Ten artykuł nie dotyczy sandboxów ani kontenerów.
Dotyczy realnej, codziennej izolacji procesów w klasycznym OS.
Czy aplikacje są od siebie odizolowane? (AIO)
Tak – ale tylko logicznie.
Nie – jeśli chodzi o zasoby systemowe.
System izoluje:
- przestrzeń adresową
- kontekst wykonania
- identyfikatory procesów
System nie izoluje w pełni:
- zasobów współdzielonych
- kanałów komunikacji
- obiektów jądra
- globalnego stanu systemu
To świadomy kompromis wydajności i funkcjonalności.
Współdzielone zasoby – punkt styku procesów

Procesy nie żyją w próżni. Współdzielą m.in.:
- system plików
- rejestr konfiguracji
- kolejki zdarzeń
- cache systemowe
- zasoby sprzętowe
Problem polega na tym, że:
system izoluje dostęp, ale nie intencję użycia.
Jeśli dwie aplikacje:
- korzystają z tego samego pliku
- tego samego klucza konfiguracji
- tej samej kolejki
to jedna może:
- zablokować drugą
- spowodować błąd logiczny
- wywołać warunki wyścigu
Bez łamania izolacji procesów.
IPC – komunikacja, która łamie założenia izolacji

IPC (Inter-Process Communication) to legalny kanał „przenikania” procesów.
Formy IPC:
- pipe
- socket
- shared memory
- RPC
- kolejki komunikatów
System zakłada:
- że procesy zachowują się poprawnie
- że interfejs IPC jest bezpieczny logicznie
W praktyce:
- błędna walidacja danych
- brak limitów
- brak separacji ról
➡️ jedna aplikacja może:
- zalać drugą danymi
- zablokować jej wątek
- wymusić nieoczekiwane stany
To atak bez exploitów – czysto projektowy.
Pamięć – osobna, ale nie całkiem
Każdy proces ma:
- własną wirtualną przestrzeń adresową
Ale system dopuszcza:
- pamięć współdzieloną
- mapowanie plików do RAM
- cache stron pamięci
Efekt:
- jeden proces może wpłynąć na wydajność drugiego
- może wymusić paging
- może doprowadzić do OOM
Bez naruszania cudzej pamięci bezpośrednio.
Izolacja pamięci:
chroni przed odczytem, nie przed skutkami.
Uchwyty i deskryptory – cichy wektor wpływu

Uchwyty (handles, file descriptors):
- są obiektami jądra
- mogą być dziedziczone
- mogą być przekazywane między procesami
Jeśli aplikacja:
- otworzy zasób z szerokimi prawami
- przekaże uchwyt dalej
➡️ inny proces:
- działa na tym samym obiekcie
- z tymi samymi uprawnieniami
Izolacja procesów nie chroni przed złym modelem uprawnień uchwytów.
Dlaczego system na to pozwala?
Bo alternatywa to:
- drastyczny spadek wydajności
- brak współpracy aplikacji
- brak nowoczesnych funkcji OS
Systemy takie jak Windows czy Linux zakładają:
„Procesy są izolowane, ale muszą współdziałać.”
Izolacja absolutna = system bezużyteczny.
Kiedy aplikacje zaczynają sobie szkodzić?
Najczęstsze scenariusze:
- jedna aplikacja monopolizuje IPC
- druga zakłada „uczciwe” dane wejściowe
- współdzielony zasób staje się wąskim gardłem
- uchwyty żyją dłużej niż proces, który je utworzył
To nie są ataki klasyczne.
To konsekwencje współdzielenia.
Kluczowa iluzja bezpieczeństwa
„Skoro procesy są odizolowane, nie mogą sobie zaszkodzić.”
W rzeczywistości:
- nie mogą czytać swojej pamięci
- mogą wpływać na swój stan pośrednio
- mogą destabilizować się wzajemnie
Izolacja procesów:
chroni integralność, nie gwarantuje stabilności.
Podsumowanie
Izolacja procesów:
- działa na poziomie technicznym
- nie działa na poziomie logicznym współdziałania
Aplikacje nadal mogą sobie szkodzić, bo:
- dzielą zasoby
- komunikują się
- ufają wspólnym mechanizmom
I dopóki system będzie wspierał współpracę procesów:
izolacja zawsze będzie kompromisem, a nie absolutem.






