Niedawno znowu miałem do czynienia z wybieraniem systemu kontroli wersji (VCS). Spotykam się z tym zagadnieniem średnio raz na rok w różnych okolicznościach i za każdym razem wyboru trzeba dokonywać od nowa. Jest tak głównie dlatego, że od kilku lat mamy do czynienia z prawdziwą eksplozją ilości systemów VCS i wreszcie jest w czym wybierać.

O tym co wybrałem i dlaczego napiszę kiedy indziej, teraz chciałem się skupić na spostrzeżeniu dotyczącym samego procesu wyboru.

Rozproszonych systemów kontroli wersji jest wiele. Przynajmniej cztery stanowią w tej chwili czołówkę: darcs, git, mercurial (hg) i bzr. Zarówno sama technologia śledzenia wersji jak i systemy w tym pomagające są niezmiernie skomplikowane. Mam tu na myśli skomplikowanie samej dziedziny problemu -- nie da się uprościć czegoś, co z natury jest trudne.

Jak zachowuje się umysł ludzki gdy ma dokonać wyboru spośród kilku trudnych do zrozumienia możliwości w niezmiernie skomplikowanym środowisku? Kieruje się intuicją!

Intuicja jest znakomitym sposobem na podejmowanie decyzji i z pewnością w czasach gdy byliśmy rasą polującą na zwierzynę w lesie nie raz ratowała nam życie i napełniała żołądki. Niestety, zawodzi kompletnie przy skomplikowanych technologicznych zagadnieniach. Tu porównywać powinniśmy starannie, krok po kroku, robiąc notatki, wypełniając tabele. Nic na skróty.

Tymczasem warto poczytać fora dyskusyjne albo posłuchać dowolnej dyskusji informatyków na temat systemów DVCS. “git jest za skomplikowany żeby się go dało używać”, “darcs jest wolny”, “mercurial jest jedynym sensownym systemem, jest wspaniały, a reszta jest gorsza”, “bazaar jest najlepszy, bo jest w pythonie i łatwo go modyfikować” -- to tylko niektóre ze stwierdzeń, jakie już usłyszałem. Problem w tym, że każde z nich wygłaszane było przez osobę, która nie zadała sobie trudu przetestowania kilku systemów! Każdy z wypowiadających się zaczął proces testowania i gdy tylko znalazł jeden system, który w miarę spełniał jego wymagania (i którego się w miarę nauczył), zaprzestawał poszukiwań. Dlaczego? Bo tak jest łatwiej! Trzeba włożyć wysiłek i przełamać się, by nauczyć się kolejnego systemu, umysł intuicyjnie odrzuca wszystko co z nim związane. Ten pierwszy wydaje nam się najlepszy, tylko dlatego, że już włożyliśmy tyle wysiłku w nauczenie się go.

Do tego dochodzi intuicja: jeśli czegoś używa więcej osób, to pewnie jest lepsze. Jeśli strona WWW dotycząca jednego systemu jest lepsza niż innego, to ów system jest lepszy. Jeśli...

Problem dotyczy nie tylko wyboru systemu kontroli wersji. Mnóstwo decyzji technologicznych podejmowanych jest bez odpowiedniego zbadania opcji, na podstawie intuicji. Zbyt często też trzymamy się kurczowo pierwszej lepiej zrozumianej opcji, zamiast włożyć wysiłek w zrozumienie wszystkich.

Znacie podobne przypadki? Nie zgadzacie się? Piszcie do mnie.

W świecie technologii często zdarza się, że względy inne niż czysto
merytoryczne decydują o tym, która technologia się upowszechni.

Miałem okazję ostatnio porównać ze sobą dwa mechanizmy zabezpieczeń
systemu Linux: SELinux (Security-Enhanced Linux) i AppArmor. Oba
przedstawiane są jako pełnoprawne rozwiązanie kontroli dostępu.

Systemy UNIX tradycyjnie opierają się na nieskomplikowanej kontroli praw
dostępu: każdy element w systemie plików ma prawa dostępu dla
użytkownika, grupy oraz wszystkich pozostałych. Nie zawsze to jednak
wystarcza -- z powodu częstych problemów z bezpieczeństwem
poszczególnych aplikacji, często potrzebne jest ograniczenie praw
dostępu konkretnym programom wyłącznie do niezbędnych dla nich plików,
czy urządzeń w systemie. Co ważniejsze, istotnym problemem w systemach
UNIX jest wszechmocny administrator (root), który ma nieograniczony
dostęp do wszystkiego.

Mechanizmy MAC (Mandatory Access Control) pozwalają na ograniczenie praw
dostępu. Poprzez zdefiniowanie polityki bezpieczeństwa można pozwolić
konkretnym aplikacjom na dostęp do konkretnych elementów systemu,
niezbędnych im do pracy. Co więcej, możliwe jest zdefiniowanie takiej
polityki bezpieczeństwa, w której nie ma wszechmocnego administratora, a
zmiana polityki bezpieczeństwa nie jest możliwa bez restartu systemu i
fizycznego dostępu do niego. Dla systemu Linux powstały dwa mechanizmy
typu MAC: SELinux i AppArmor.

SELinux jest rozwiązaniem nieco starszym. Początkowo opracowane w NSA
(National Security Agency), zostało szybko przyjęte m.in. przez Red Hata
jako rozwiązanie bezpieczeństwa dla systemów Red Hat Enterprise
Linux. Pozwala na zdefiniowanie kompletnej polityki bezpieczeństwa dla
całego systemu i całkowite wzajemne odizolowanie od siebie aplikacji.

AppArmor to alternatywne rozwiązanie, opracowane w firmie Immunix, a
następnie rozwinięte przez Novella. Cele są tu nieco inne niż dla
SELinux: AppArmor służy do chronienia systemu przed konkretnymi
zagrożeniami, ze strony konkretnych aplikacji. Z założenia niewielka
część programów w systemie będzie miała zdefiniowane profile
bezpieczeństwa. Będą to na ogół programy mające kontakt ze światem
zewnętrznym, takie jak np. serwisy sieciowe.

Najbardziej zaognionym punktem spornym w dyskusjach na temat wyższości
jednego rozwiązania nad drugim jest ich podejście do oznaczania plików w
systemie. SELinux operuje na i-węzłach -- odpowiednio oznaczonej
konkretnej zawartości w systemie plików. AppArmor używa tradycyjnych
ścieżek dostępu.

Zwolennicy SELinux twierdzą, że używanie ścieżek dostępu nie zapewnia
odpowiedniego bezpieczeństwa. Można przecież tworzyć dowiązania (hard
links), manipulować przestrzenią nazw systemu plików, czy podmieniać
zawartość plików. W końcu ścieżka do pliku to wyłącznie wskazanie --
"plik, który znajduje się pod tym adresem", nie zaś sama zawartość
pliku. Dlatego SELinux wymaga oznaczania i-węzłów, czyli konkretnej
zawartości, za pomocą specjalnych metek. Do nich później odwołuje się
polityka bezpieczeństwa.

Entuzjaści AppArmor odpowiadają na to: racja, ścieżki dostępu mają swoje
wady. Są za to nieskomplikowane, intuicyjne w użyciu, a wszyscy są do
nich przyzwyczajeni. Politykę bezpieczeństwa tworzy się więc łatwo.

Trudno jest porównać ze sobą mechanizmy, które w założeniach mają
spełniać różne role. W praktyce jednak często staje się przed wyborem,
którego z nich użyć.

Teoretycznie SELinux jest rozwiązaniem technologicznie lepszym. Pozwala
na zdefiniowanie kompletnej polityki bezpieczeństwa, odseparowanie od
siebie przepływów danych, zabezpieczenie całego systemu. Definiowanie
dostępu do konkretnych i-węzłów zabezpiecza system przed wieloma
rodzajami ataków. Są też jednak minusy: i-węzły w systemie plików trzeba
oznaczyć i pilnować, by pozostały oznaczone. Trudniej jest robić kopie
bezpieczeństwa, bo trzeba dbać o zachowanie metadanych. Politykę
bezpieczeństwa definiuje się też trudno.

W praktyce więc AppArmor, pomimo że ma mniejsze możliwości, może się
okazać znacznie lepszym rozwiązaniem. W wielu zastosowaniach lepiej mieć
dobrze wdrożony i działający AppArmor dla ograniczonej liczby aplikacji,
niż nie do końca zaimplementowany SELinux dla całego systemu.

Dochodząc do tytułu tego artykułu: w teorii SELinux jest rozwiązaniem
bardziej zaawansowanym technologicznie, ale w praktyce AppArmor spisuje
się lepiej. Wystarczającym powodem jest tu trudność użycia: są znacznie
większe szanse, że administrator poprawnie zdefiniuje profile
bezpieczeństwa w AppArmor, niż że zrobi to dobrze dla SELinux, a nawet
najlepsze technologicznie rozwiązanie przy źle zdefiniowanej polityce
bezpieczeństwa nie zabezpieczy systemu.

Macie przemyślenia na ten temat? Piszcie do mnie, proszę. Podejmę dyskusję w przyszłych artykułach.

Przysłuchiwałem się niedawno dyskusji podczas spotkania Klubu Informatyka PTI. Samego spotkania sprawozdawać nie będę, zrobili to znacznie lepiej inni -- napiszę jednak o czymś, co uważam za istotne dla sprawy podpisu elektronicznego.

W samej dyskusji brałem udział biernie, tylko się przysłuchując. Nie uważałem, żebym miał wiele do dodania, w końcu dyskutowali ludzie, którzy od lat zajmują się tym tematem. Rozmowa toczyła się wokół problemów z adopcją podpisu elektronicznego w Polsce. Jako główne problemy wymieniane były ceny (sprawdziłem -- certyfikat kwalifikowany to minimum 300zł rocznie, co zakrawa na żart) oraz brak świadomości istnienia podpisu elektronicznego w społeczeństwie.

Dodałbym trzeci powód braku adopcji. Choć zapewne nieznaczący w ujęciu statystycznym, w gronie ludzi zajmujących się informatyką może okazać się istotny. Dlaczego ja sam nie używam podpisu elektronicznego?

Bo się boję.

W pędzie do popularyzacji podpisu elektronicznego zapomnieliśmy o edukacji. Podpis taki daje co prawda wiele korzyści, ale niesie także ze sobą zagrożenia. O tych drugich mało kto mówi, mam też wrażenie, że mało kto zadaje sobie trud pełnego ich zrozumienia.

Centra certyfikacyjne sprzedadzą nam certyfikaty, karty kryptograficzne, czytniki kart, wszystko z zapewnieniem, że są to produkty najwyższej klasy bezpieczeństwa. Istotnie tak jest. Problem jednak w tym, że większość klientów owe wysokiej klasy produkty podłączy do swojego komputera PC, prawdopodobnie z systemem Microsoft Windows. W najlepszym przypadku nie będzie wiadomo, co się na nim dzieje, jaki kod jest wykonywany, z czym się komunikuje i co robi. W rzeczywistości, czyli w większości przypadków, ów komputer będzie jednym wielkim zoo, gdzie wśród żyraf (programy obserwujące zachowania) i bawołów (wirusy) będą zwinnie bujać się na linach małpy (keyloggery).

Owszem, szybko odpowiedzą eksperci -- ale to nie ma znaczenia, bo podpis generowany jest na specjalnej bezpiecznej karcie z mikroprocesorem! Nie można go ukraść i nie można nim nic podpisać, gdy karta nie jest włożona do czytnika. Tak faktycznie jest. Niestety, nadal można nim podpisać kilka różnych rzeczy zamiast jednej. Temu zaradzi czytnik z klawiaturą (pin-padem) -- zakrzykną eksperci! To prawda -- nawet wtedy jednak pozostaje główny problem: użytkownik nie wie, co podpisuje.

Pamiętajmy, że to co akurat wyświetla na ekranie nasz komputer, nie musi mieć żadnego związku z tym, co do podpisania dostaje czytnik. I tak prawie zawsze podpisem opatruje się funkcję skrótu dokumentu, a nie cały dokument, użytkownik zaś na ekranie widzi dokument. Głównym jednak problemem dla mnie jest to, że nie mogę być pewien czy faktycznie podpisuję to, co widzę na ekranie.

Jeśli ktoś w tym momencie twierdzi, że taki atak nie jest prawdopodobny, to jest naiwny. Wiele osób twierdzi, że programy przechwytujące naciśnięcia klawiszy (keyloggery) to problem wydumany. Tym polecam pobudkę, na przykład poprzez przeczytanie o Mumbai, gdzie wręcz wymaga się od kawiarni internetowych instalowania takich programów.

Cały problem w tym, że mając bezpieczną infrastrukturę do podpisu elektronicznego, wprowadzamy do niej element, któremu nie można ufać: komputer PC. Wydawało mi się to tak oczywistym przeoczeniem, że nie chciałem wierzyć, że twórcy ustaw o podpisie elektronicznym nie pomyśleli o tym problemie. Wczytałem się więc w akty prawne. Co się okazało? Pomyśleli -- i nawet opisali precyzyjnie jakie wymagania musi spełniać "bezpieczne urządzenie do składania podpisów elektronicznych":

§ 6. Bezpieczne urządzenie do składania podpisów elektronicznych oraz bezpieczne urządzenie do weryfikacji podpisów elektronicznych mają możliwość obliczania i prezentowania przynajmniej jednej z funkcji skrótu w stosunku do danych służących do weryfikacji bezpiecznego podpisu elektronicznego lub poświadczenia elektronicznego, będących dla osoby składającej bezpieczny podpis elektroniczny lub weryfikującego bezpieczny podpis elektroniczny punktem zaufania. (ROZPORZĄDZENIE RADY MINISTRÓW z dnia 7 sierpnia 2002 r., Dz. U. Nr 128, poz. 1094) (podkreślenie autora)

Oto i rozwiązanie mojego problemu -- mam komputer PC, który wyświetla mi na ekranie dokument i pokazuje jego funkcję skrótu. Równocześnie, ów dokument przesyłany jest do zaufanego urządzenia zewnętrznego (najlepiej z otwartym, audytowalnym), które niezależnie liczy funkcję skrótu i wyświetla mi ją na wbudowanym ekranie LCD. Do urządzenia zewnętrznego mam zaufanie, wiem też, że jego oprogramowania nie da się zmienić, bo jest zapisane w pamięci ROM. Mogę więc porównać oba skróty i spokojnie autoryzować podpis, wiedząc co podpisałem.

Nie rozumiem dlaczego na stronach Sigillum jest informacja, że bezpiecznym urządzeniem do składania i weryfikacji podpisu elektronicznego zgodnie z wymaganiami ustawy i rozporządzenia są zestawy czytnik + komputer PC + oprogramowanie. W żaden sposób za bezpieczny (czyli spełniający wymagania opisane w Rozdziale 2 rozporządzenia) nie może być uznany komputer PC z oprogramowaniem, chociażby dlatego, że nie ma kontroli nad wyświetlanym obrazem na ekranie oraz nad danymi wpisywanymi z klawiatury. Wytłumaczeniem nie może być ograniczenie technologiczne, bo istnieją czytniki z wyświetlaczem -- i jak przypuszczam, wynik funkcji skrótu potrafią wyświetlić.

Nie jestem bynajmniej jedynym, który zauważył problem. Przykładem może być chociażby praca "Digital signature in insecure environments".

W profesjonalnej analizie o bezpieczeństwie zawsze mówi się jako o kompromisie. Można mieć system albo bezpieczny, albo wygodny w użyciu. Na drugim wykresie pokazać można ryzyko finansowe: ile klient ryzykuje, wybierając mniej bezpieczny system. O ile wybory te są świadome, można dobrze dobrać politykę bezpieczeństwa do realnych wymagań. W przypadku podpisu elektronicznego jestem w stanie zrozumieć, że w wielu zastosowaniach biznesowych (takich jak np. masowe podpisywanie faktur wykonywane na zaufanym i zabezpieczonym systemie) obecne rozwiązania mają sens i są rozsądnym kompromisem. Nie jest tak jednak w przypadku osób fizycznych. Tu systemy są znacznie gorzej zabezpieczone (to dopiero eufemizm!), a względne ryzyko finansowo-prawne nieporównywalnie większe.

Jeśli chodzi o mnie, podpisując na komputerze z systemem Linux czułbym się lekko niekomfortowo, ale zaakceptowałbym ryzyko, w końcu system jest audytowalny i kod systemu i aplikacji jest regularnie oglądany przez wiele osób. Na moim MacBooku z Mac OS X byłbym już dużo ostrożniejszy, zaś z Windows nie odważyłbym się na podpis w ogóle. Dopóki więc na rynku nie będą powszechnie dostępne czytniki kart z klawiaturą (pin-padem), wyświetlaczem pokazującym funkcję skrótu oraz audytowalnym oprogramowaniem, dopóty nie będę używał podpisu elektronicznego, który może rodzić dla mnie skutki prawne.