gefira blog

Na swoim Ubuntu używam Enterprise Architecta uruchamianego pod Wine. Pomimo tego, że lubię EA to jednak nie mam zbyt wielkiej nadziei na to, że Sparx Systems udostępni wersję opensource’ową w najbliższej przyszłości. Nie mam dostępu do źródeł EA, więc podwójnie nie mogę wierzyć temu jak ten program działa. Szczęśliwie, dzięki AppArmor, możliwe jest ograniczenie dostępu EA do wskazanych zasobów systemu, dzięki czemu wiem, że EA nie zagląda niepotrzebnie do ~/.ssh, /sbin czy innych miejsc, które – według mnie – nie są EA potrzebne do szczęścia.

Odkładając jednak na bok historie o koniach trojańskich wprowadzanych celowo przez producentów popularnego oprogramowania bez dostępu do źródeł, warto podejść do kwestii EA bardziej systematycznie i odpowiedzieć sobie na pytania, które stawia autor tej książki.

1. Co właściwie chcę ochronić?
   • Chcę ochronić prywatne dane swoje i swoich klientów, które znajdują się w systemie i podlegają przetwarzaniu przez EA. Dodatkowo chcę ochronić sam system – binaria, biblioteki, pliki konfiguracyjne itp.
2. Jakie są zagrożenia dla zasobów, które chcę ochronić?
   • Ze strony EA nie przewiduję większych kłopotów, nie przewiduje celowych niecnych działań. Bardziej obawiam się tego, że EA nie był projektowany do pracy z Linuksem i może niechcący żądać dostępu do prywatnych danych oraz do innych core’owych zasobów systemu. Dane te i zasoby mogłyby być np. cache’owane przez EA w swoich strukturach danych (w plikach konfiguracyjnych, bazach z projektami) przez co mogłyby niechcący wyjść poza mój system gdybym np. chciał komuś wysłać swój projekt .EAP. Inną kwestią jest to, że EA nie podlega w żaden sposób aktualizacji oprogramowania takiej jak wszystkie inne aplikacje Ubuntu – nie jest instalowany jako pakiet Ubuntu więc informacje o nowych wersjach EA otrzymuję z opóźnieniem. Może więc zdarzyć się sytuacja, że będzie istniał exploit dla EA, który będzie można uruchomić w moim systemie pomimo tego, że reszta systemu będzie na bieżąco aktualizowana. Exploit ten mógłby pozwolić na wydostanie się przez sieć z systemu np. danych dotyczących projektów dla klientów.
3. Na ile dobrze proponowane przeze mnie rozwiązanie chroni zasoby?
   • AppArmor jest dojrzałym rozwiązaniem stosowanym w o wiele bardziej zaawansowanych scenariuszach serwerowych i  otoczenie EA przez AppArmor oznacza użycie części możliwości AA. AppArmor ma wszystkie te możliwości, na których mi zależy – pozwala na wskazanie, do których zasobów może lub nie może mieć dostęp EA. Używam standardowej, sprawdzonej, funkcjonalności AA.
4. Jakie zagrożenia wprowadza proponowane rozwiązanie?
   • Wprowadzam do systemu nowy element – AppArmor chroniący EA – istnieje więc ryzyko, że zmiany które wprowadzam same będą zawierały błędy, że AppArmor będzie zawierał błędy, które negatywnie wpłyną na bezpieczeństwo i zabezpieczenia systemu. Nie przewiduję zagrożeń związanych z tym, że zwiększy się poziom skomplikowania interakcji EA oraz Wine z resztą systemu, ostatecznie po to chcę wprowadzić AppArmor, aby ograniczyć, a nie zwiększyć, kontakty EA i Wine z pozostałymi elementami systemu.
5. Jakie są koszty wprowadzonego rozwiązania?
   • Podstawowym kosztem jest czas poświęcony na utworzenie i utrzymanie odpowiedniej konfiguracji AppArmor. EA jest relatywnie małą aplikacją, więc kilka godzin wystarczy na utworzenie początkowej konfiguracji. Konfiguracja, na której mi zależy powinna być ścisła, chcę więc ograniczyć dostęp EA do konkretnych wersji bibliotek potrzebnych do działania – wiąże się więc z tym to, że przy zmianach wersji bibliotek (np. nowa wersja X-a, upgrade do nowszej wersji Ubuntu) potrzebne będą zmiany w konfiguracji AppArmor, przewiduję, że zajmie to także kilkadziesiąt minut miesięcznie. Kosztem jest także konieczność aktualizacji AppArmor do nowszych wersji – to jednak odbywa się automatycznie, Ubuntu pobiera nowe wersje oprogramowania do instalacji i pyta mnie o zgodę na instalację, nie zajmuje to więcej niż kilkanaście minut miesięcznie. Inną sprawą jest zapotrzebowanie AA na zasoby sprzętowe (procesor i miejsce na dysku), aczkolwiek te są bardzo małe i praktycznie niezauważalne przy wszystkich innych zainstalowanych aplikacjach.
6. Czy warto wprowadzić proponowane zabezpieczenia aby zminimalizować zagrożenia, biorąc pod uwagę koszty, które muszę ponieść oraz zagrożenia, które mogą zostać wprowadzone?
   • Pomimo tego, że nie przewiduję, aby zagrożenia ze strony EA były duże to koszty, które muszę ponieść, oraz zagrożenia ze strony AA są jeszcze mniejsze – tak, warto wprowadzić proponowane zabezpieczenia.

Skoro już podjąłem decyzję o użyciu AA, to musimy utworzyć profil Enterprise Architecta dla AppArmor, który będzie zawierał reguły mówiące AA na co pozwalamy Enterprise Architectowi. Profile AA rozszerzają, nie zastępują, standardowe uprawnienia UNIX-owe do zasobów systemu. Nadal więc występują rwx, setuid, sticky bit i przyjaciele, ale dodatkowo AA pozwala na ściślejsza kontrolę dostępu.

AppArmor operuje na ścieżkach do plików – trzeba wskazać, który program chcemy audytować podając właśnie jego ścieżkę. Ponieważ EA jest uruchamiany pod Wine, to AA nie widzi tak naprawdę EA tylko Wine. Na przyklad, u mnie na pulpicie ikonka EA uruchamia takie polecenie:

env WINEPREFIX="/home/dsuch/.wine" wine "C:\Program Files\Sparx Systems\EA\EA.exe"

więc dla AA programem, który jest uruchomiony, nie jest EA tylko Wine.

Nie chcę utworzyć profilu dla całego Wine’a, tylko dla EA, potrzebujemy w takim razie małego wrappera, skryptu shellowego, który opakuje nam EA wywoływane pod Wine i będzie miało swoją unikalną ścieżkę, którą będzie można audytować. Wrapper ten  u mnie jest umieszczony w /home/dsuch/bin/ea.sh i ma taką postać:

wine ~/.wine/drive_c/Program\ Files/Sparx\ Systems/EA/EA.exe

Taki skrypt można już potraktować poleceniem aa-genprof. Jak czytamy w manualu (man aa-genprof), program ten wspomaga tworzenie profili dla AA. To co zrobi aa-genprof, to utworzenie pustego profilu dla wrappera /home/dsuch/bin/ea.sh, zaznaczenie w logu auditd (domyślnie /var/log/audit/audit.log) albo w  /var/log/messages, że rozpoczyna się proces tworzenia profilu, aktywowanie profilu w trybie complain (nauki), a następnie aa-genprof będzie czekał aż pochodzę sobie po EA, cały czas rejestrując w logu do jakich zasobów dostępu żąda EA. Gdy już skończę pracować z EA, aa-genprof zada mi serię pytań – nad którymi warto zastanowić się – na temat tego, czy EA faktycznie powinien mieć dostęp do zasobów, z których korzystał. Profile są prostymi plikami tekstowymi o określonej składni, można więc dodatkowo tune’ować je manualnie, już po ich utworzeniu. Skończony profil można uruchomić w trybie enforce, co spowoduje, że AppArmor zacznie stosować reguły zdeklarowane w profilu.

Do samego aa-genprof, jak i do innych toolsów z rodziny AppArmor istnieje dobra dokumentacja, spójrzmy więc na ostateczny profil, który można pobrać tutaj.

Pierwszą rzeczą, którą trzeba zauważyć jest to, że profil zawiera subprofil dla Wine. Ma to sens, ponieważ wrapper uruchamia Wine w podprocesie, i chcemy w profilu określić jakie możliwości powinien lub nie powinien mieć Wine uruchamiany w kontekście tego konkretnego wrappera, dlatego właśnie profil wrappera zawiera subprofil Wine.

Profil wrappera zawiera 3 polecenia:

• #include <abstractions/base> – includuje wszystkie reguły z /etc/apparmor.d/abstractions/base do bieżącego profilu (do profilu wrappera /home/dsuch/bin/ea.sh). Dzięki includowaniu można wyodrębnić sobie zestaw reguł wspólnych dla różnych profilowanych aplikacji
• owner @{HOME}bin/ea.sh r,- pozwala w ogóle na odczyt skryptu. Bez tej reguły, pomimo tego, że w sensie uprawnień UNIX-owych jestem właścicielem /home/dsuch/bin/ea.sh i wrapper ma odpowiednie aytrybuty (-rwx——), to jednak nie mogę odczytywać tego skryptu.
  • Chwili uwagi wymaga też alias @{HOME}. Mamy do niego dostęp dzięki użyciu #include <tunables/global> na samej górze profilu, który z kolei includuje między innymi /etc/apparmor.d/tunables/home, w którym to pliku określone jest gdzie w naszym systemie znajdują się katalogi domowe użytkowników. W razie gdyby ktoś w swoim systemie stosował nie /home, ale np. /export/home, to może tam wskazać lokalizację katalogów domowych użytkowników. Dzięki temu w profilach możemy właśnie pisać @{HOME} a nie /home. Po prostu kolejna warstwa abstrakcji.
  • Z kolei prefiks owner mówi AA, żeby sprawdzić, że jestem właścicielem pliku @{HOME}bin/ea.sh – mogłoby zdarzyć się tak, że istniałby w systemie /home/gucio/bin/ea.sh, który miałby swój profil AA taki sam jak mój, i dzięki użyciu prefiksu owner AA nie pozwoliłby mi na uruchomienie wrappera Gucia, nawet gdyby wrapper Gucia miał ustawiony atrybut o+x, który standardowo pozwoliłby mi na jego uruchomienie.

• /usr/bin/wine cx, – pozwala wrapperowi na uruchomienie Wine’a (flaga x), oraz mówi, że istnieje subprofil dla Wine’a uruchamianego w ramach aktualnego profilu (flaga c, czyli child).

Na tym kończy się profil dla samego wrappera, dalej w profilu pojawia się subprofil, który określa do czego ma dostęp Wine uruchamiany z poziomu wrappera. Subprofil celowo jest wybitnie restrykcyjny i wskazuje na konkretne wersje bibliotek, z których może korzystać Wine uruchamiający EA. Subprofil można podzielić na kilka części:

• Podstawowe zależności – tutaj nie ma wielkiego wyboru, trzeba pozwolić na ich uruchomienie, są to core’owe komponenty, które przewijać się mogą w większości aplikacji (ld, libc, libpthread itp.)
• Fonty – cóż, fonty na pewno są potrzebne w aplikacji okienkowej. Nie miałem pojęcia, że w aż tyle miejsc trzeba zajrzeć, żeby aplikacja miała dostęp do fontów.
• Locale – no tak, locale na pewno są potrzebne.
• X + keymapa – także przyda się w aplikacji okienkowej
• Wine, core + biblioteki – tu też nie ma wyboru, Wine nie jest mały, trzeba pozwolić na uruchomienie kilku podprocesów i wczytanie bibliotek.
• Wine, zasoby z pseudodysku C: – kolejne zależności Wine, tym razem bliższe systemowi Windows.
• /proc/cpuinfo i /proc/meminfo – potrzebne Wine do szczęścia.
• Ustawienia EA – tutaj dopiero zaczynają się ustawienia specyficzne dla EA. Nie ma wyboru, trzeba pozwolić EA na zajrzenie i wczytanie swoich własnych danych i bibliotek.
• Różne – tutaj nie ma nic ciekawego, nie ma też co dziwić się, że jest potrzebny dostęp do /etc/passwd, w jakiś sposób aplikacja musi sprawdzić gdzie np. jest mój katalog domowy. Wywołuje więc polecenie systemowe, które zagląda do /etc/passwd, odczytuje lokalizację mojego $HOME i zwraca wynik do aplikacji. Hasha i salta hasła w /etc/passwd i tak przecież nie ma.
• Ustawienia specyficzne dla moich projektów – wszystkie projekty, które wymagają jakichkolwiek diagramów UML, znajdują się w podkatalogach katalogu /home/dsuch/projects/, EA musi więc mieć dostęp do odczytu do tych podkatalogów. Dodatkowo, same projekty .eap przechowywane są zawsze w katalogach o nazwie “doc”, EA powinien mieć więc możliwość zapisywania do swoich plików i zakładania locka na pliku .ldb (flaga k oznacza granta na zakładanie locka na danym pliku).
• Zasoby, do których uprawnienia EA odebrałem- tu jest ciekawiej. Zasoby te można podzielić na trzy kategorie:
  • kryptobiblioteki – być może byłyby potrzebne gdybym EA dopiero instalował, np. EA potrzebowałby ich do sprawdzenia kluczy licencyjnych. Właściwie to jest dość pozytywne, że EA chce korzystać z możliwości krypto, które oferuje dany system a nie z własnych “innowacji”. Inna sprawa to to, że nie mam dostępu do źródeł EA, więc nie wiem na ile solidnie jest cała kryptografia w EA wykonana.
  • dostęp do sieci – to nie powinno być potrzebne. Nie mam pojęcia dlaczego, ale EA chciał koniecznie otwierać sockety TCP. Używam EA w wersji Professional Edition, nie łączę się więc z żadnymi bazami danych i nie chcę, aby EA otwierał jakiekolwiek połączenia. Z pewnością jest to sprawa do zgłoszenia do supportu SparxSystems, zobaczymy co support na to powie.
  • lista urządzeń SCSI (/proc/scsi/scsi) – teoretycznie nic groźnego, ale jeśli wszystko działa poprawnie bez tego to nie ma potrzeby nadawać takich uprawnień. To też jest sprawa dla supportu.

Na tym kończy się mój profil AppArmor dla Enterprise Architecta. Jestem zadowolony z tego, że EA nie wygłupia się i nie sięga tam, gdzie nie trzeba. Sprawę z otwieraniem socketów oraz SCSI zgłoszę w supporcie SparxSystems a odpowiedź opiszę tutaj. Widać wyraźnie, że profil w większości składa się z reguł dla Wine, nie dla EA – gdybym używał więcej aplikacji pod Wine to mógłbym część commonową dla Wine umieścić w osobnym profilu, który includowałbym w profilu dla EA.

Nie kończy się jednak na tym AppArmor, to dopiero czubek góry lodowej – zachęcam do zapoznania się z dokumentacją AppArmor i rozpoznania bardziej zaawansowanych możliwości.

Support społeczności Ubuntu dla AppArmor znajduje się na Launchpadzie, support komercyjny dla Ubuntu i AppArmor świadczy Canonical, a w Polsce support komercyjny dla Ubuntu oraz AppArmor oferuje gefira / the knowledge company.

@fourthrealm