🚀 go-pugleaf

Chciałbym przedyskutować problem, jak powinien wyglądać system 
operacyjny na miarę drugiej dekady XXI wieku. Windowsy i Uniksy to 
systemy, których filozofia konstrukcji tkwi w latach 1970, w czasach, 
kiedy nie było wirusów ani crackerów. Powoduje to, że dzisiaj te systemy 
ledwo radzą sobie z zagrożeniami, w zasadzie co chwila przychodzą newsy, 
że gdzieś jest dziura i już ktoś gdzieś przez nią się włamał.

Przyczyna słabości Windowsów i Uniksów tkwi m.in. w pochodzącej z lat 
70. filozofii: "Jeśli aplikacja czegoś chce, musimy jej to dać". Ja bym 
widział zupełnie inną filozofię dla OS-a nowej generacji:

1. Przypuśćmy, że aplikacja chce otworzyć socket, żeby wysłać coś przez 
sieć. System operacyjny, by default, ODMÓWI tego aplikacji, o ile ta nie 
jest zarejestrowana w systemie jako aplikacja używająca połączeń 
sieciowych (np. przeglądarka www, klient poczty). Oczywiście lista 
takich zarejestrowanych aplikacji jest jawna i użytkownik może z niej 
usunąć program, który mu się nie podoba. W ten sposób nie ma już 
sytuacji, że każdy byle notepad może sobie słać w sieć, co mu się podoba.

2. Aplikacja może mieć swoje własne pliki i robić z nimi co chce, ale by 
default nie ma dostępu do plików użytkownika. Jeśli aplikacja poprosi 
system o dostęp do plików użytkownika, wówczas system wyświetli 
użytkownikowi przed nosem okienko wyboru pliku, użytkownik wybierze 
konkretny plik i aplikacja tylko w ten sposób dostanie uchwyt do już 
otwartego pliku. Tak samo, jeśli w tym okienku użytkownik zaznaczy, że 
chce dać aplikacji plik w trybie read only, to aplikacja tylko takim go 
dostanie i żadne freopen() jej nie pomoże, bo system odmówi i już.

Z powyższego widać, że zwykły program, który nie jest na żadnej liście 
przywilejów, ma w systemie możliwości porównywalne z niepodpisanym 
apletem javy w przeglądarce www. Gdyby system traktował tak na dzień 
dobry każdą aplikację, wówczas wirusy, robaki i trojany miały by poważne 
problemy ze skutecznym działaniem. System miałby też większą tolerancję 
dla błędów, bo nawet kod podrzucony przez przepełnienie stosu wykonywał 
by się z tak samo ograniczonymi uprawnieniami.

Oczywiście pozostaje problem aplikacji uprzywilejowanych, czyli takich 
które są na listach nieograniczonego dostępu do socketów czy plików 
użytkowników, ale przynajmniej zawęzilibyśmy słabe punkty systemów do 
tychże aplikacji.

3. Jeszcze jedna kwestia - np. obecnie Firefox to są dwa procesy, jeden 
to jest okno główne, drugi to jest kontener dla pluginów. Może należało 
by budować takie aplikacje, jako agregaty złożone np. z 10 procesów, z 
których każdy robi swoje i z pozostałymi komunikuje się przez ściśle 
zdefiniowane interfejsy. Np. odrębny proces tylko do obsługi http - 
tylko on musiałby mieć przywilej socketa. Wówczas jeszcze bardziej 
zawężamy punkty możliwego ataku na system - np. zhackowanie GUI 
przeglądarki już nic nie da, bo proces GUI nie ma uprawnień do socketa, 
a interfejs do procesu http jest taki, że uniemożliwi bezpośrednie 
kontrolowanie socketa.

Napiszcie, co sądzicie o tych pomysłach. Ja wyjeżdżam na przedłużony 
weekend, więc ustosunkuję się do krytyki po powrocie.

-- 
Pozdrawiam,

Tomek