Mastodawn

Prywatność i cyberbezpieczeństwo to nie są hobbystyczne fanaberie dla ludzi w foliowych czapeczkach. Skompromitowane urządzenie mobilne to bezpośrednie zagrożenie dla Twojego życia osobistego, finansów i spokoju psychicznego.

Właśnie ruszyłem ze swoim blogiem, a to mój pierwszy wpis:
🔗 https://meridian.bearblog.dev/droga_do_grapheneos/

Opisuję w nim historię z ukrytym korporacyjnym MDM na moim telefonie i to, jak techniki Incident Response oraz przejście na GrapheneOS pozwoliły mi odzyskać kontrolę.

To mój debiut, dlatego bardzo zależy mi na Waszym feedbacku. Co myślicie o tym tekście? Dajcie znać w komentarzach, czy taka tematyka Was interesuje i czy chcecie kolejne wpisy o konfiguracji i hardeningu GrapheneOS! 🛡️📱

#GrapheneOS #Cybersecurity #Privacy #Prywatnosc #Bezpieczenstwo #FOSS #MobileSecurity #PlFediverse #Blog

Jak okiełznałem system z MDM. Moja droga do GrapheneOS

W świecie cyberbezpieczeństwa często rozmawiamy o "modelach zagrożeń" (Threat Models) w sposób czysto teoretyczny. Analizujemy tabelki, czytamy dokumentację ...

Meridian

Show thread

Marek idkfa 🌕Jun 5

@meridian dlaczego uważasz fdroid za przestarzały?

Show thread

meridian 6d ago

@kayo77 F-Droid jest świetny ideologicznie, ale technicznie utknął w przeszłości i wymusza spore kompromisy w kwestii bezpieczeństwa. Uważam go za przestarzały z trzech głównych powodów:

Stare Target SDK: Wiele aplikacji w repozytorium nie jest aktualizowanych pod kątem nowoczesnych API Androida. Przez niskie Target SDK aplikacje te mogą obchodzić współczesne mechanizmy obronne systemu (np. nowoczesną izolację w piaskownicy czy restrykcyjne zarządzanie uprawnieniami).

Model podpisywania aplikacji: F-Droid sam buduje kod i podpisuje pakiety własnym kluczem kryptograficznym, zamiast kluczem dewelopera. Centralizuje to zaufanie (w razie kompromitacji serwerów F-Droida zagrożone są aktualizacje) i uniemożliwia łatwą migrację na oficjalne wydania (np. z GitHuba) z powodu konfliktu podpisów.

Zacofany instalator: Oficjalny klient przez lata ignorował nowoczesne, bezpieczne API systemowe Androida służące do zarządzania pakietami. Wprowadzanie tak podstawowych funkcji jak automatyczne i bezobsługowe aktualizacje w tle (Unattended Updates) zajęło im lata, co mocno odstaje od dzisiejszych standardów UX i security.

Właśnie dlatego w świecie GrapheneOS standardem staje się pobieranie aplikacji FOSS bezpośrednio od deweloperów (np. przez Obtainium)

Show thread

Marek idkfa 🌕

@meridian a jaką masz pewność że deweloper czegoś nie dokleił? Przypomnę tylko agenta Tactical RMM do którego dev dodał koparkę. Poza tym nie wiem dlaczego winisz fdroida za stare SDK aplikacji w nim będących. To nie powinno być rola deva?

Show thread

meridian 6d ago

@kayo77 Przypadek Tactical RMM to świetny przykład, ale dotyczył systemu desktopowego, gdzie aplikacja uruchomiona z uprawnieniami administratora ma pełny dostęp do wszystkiego. Na GrapheneOS architektura opiera się na zasadzie zerowego zaufania do kodu (Zero Trust) i rygorystycznej izolacji (sandboxingu). F-Droid w żaden sposób nie audytuje kodu pod kątem ukrytych złośliwych funkcji (jak wspomniana koparka) – sprawdza jedynie, czy jest on otwartoźródłowy. Przed złośliwym deweloperem nie chroni sklep, a wyłącznie piaskownica systemu operacyjnego.

Co do Target SDK: naturalnie, to deweloper pisze kod, ale to polityka F-Droida pozwala na dystrybucję porzuconych i potencjalnie niebezpiecznych aplikacji. Dla porównania – Google Play czy repozytoria zgodne z Verified Apps od Privacy Guides usuwają pakiety niespełniające współczesnych standardów bezpieczeństwa. F-Droid świadomie akceptuje i dystrybuuje aplikacje ze starym SDK, które mogą omijać nowoczesne mechanizmy obronne Androida.

Właśnie dlatego mój obecny setup eliminuje te ryzyka i przewyższa model F-Droida:

Używam Obtainium, więc pobieram oryginalne paczki bezpośrednio z wydań dewelopera, bez pośrednictwa serwerów F-Droida (w przypadku F-Droida kompromitacja ich serwera oznacza zagrożenie dla wszystkich aplikacji podpisanych ich centralnym kluczem).

Używam App Verifiera, który pilnuje integralności i automatycznie weryfikuje podpisy kryptograficzne.

Dodatkowo bazuję na weryfikacji skrótów kryptograficznych (SHA-256) dostarczanych i sprawdzanych przez zaufaną społeczność na forum GrapheneOS.

Taki model (Decentralizacja + Kryptografia + Silny Sandboxing) daje mi realne, techniczne bezpieczeństwo. F-Droid daje często złudne poczucie ochrony, oparte na ślepym zaufaniu do jednej, centralnej instytucji.

Show thread

Kierunkowy74 6d ago

@meridian @kayo77
>F-Droid daje często złudne poczucie ochrony, oparte na ślepym zaufaniu do jednej, centralnej instytucji.

Zarzut, który rykoszetuje przeciw GNU/Linuksowi. Oficjalne repozytoria z dystrybucji typu Debian/Ubuntu/Fedora/(...) sprowadzają się do traktowania wszystkich programów - od jądra i usług systemowych, przez pakiety biurowe i przeglądarki, do gier jako integralnych części systemu operacyjnego...

Show thread

meridian 6d ago

@74 Argument o elektrośmieciach wynika z mylenia dwóch parametrów. O tym, na jak starym telefonie ruszy aplikacja, decyduje minSdkVersion. Podnoszenie bezpieczeństwa kodu nie odcina starych urządzeń. Z kolei targetSdkVersion to informacja dla nowych systemów (jak Android 14/15 czy GrapheneOS), jak aplikacja ma chronić dane. Jeśli deweloper utrzymuje tam stary numerek, to po to, by program na nowym smartfonie mógł legalnie omijać restrykcje prywatności (np. dostęp do schowka czy lokalizację). Akceptując takie pakiety, F-Droid pozwala na dziurawienie mechanizmów obronnych systemu.

Porównanie do repozytoriów Debiana czy Fedory to błąd logiczny. Na desktopie soft z repo ma domyślnie dostęp do całego katalogu domowego (/home) może czytać klucze SSH czy sesje przeglądarek. Tam zaufanie do repozytorium musi być absolutne. Na GrapheneOS rządzi bezkompromisowy sandboxing na poziomie jądra. System nie ufa nikomu i dzięki Storage Scopes izoluje programy tak głęboko, że nie widzą one plików innych aplikacji. To nie sklep ma mnie chronić przed złośliwym kodem, od tego jest pancerna piaskownica OS.

Skoro system i tak izoluje kod, kluczowa staje się zdecentralizowana kryptografia. F-Droid w głównym repozytorium domyślnie sam kompiluje kod i podpisuje paczki swoim centralnym kluczem kompromitacja ich infrastruktury tworzy gigantyczne ryzyko dla całego softu naraz. W moim setupie z Obtainium omijam ten problem i pobieram paczki podpisane unikalnymi kluczami deweloperów bezpośrednio z ich GitHubów. Za kontrolę integralności odpowiada App Verifier, wspierany przez weryfikację skrótów SHA-256 przez społeczność GrapheneOS. F-Droid sprawdza jedynie licencję, a nie złośliwe funkcje. Ślepe zaufanie do niego to podejście z 2010 roku. Model silny sandbox + Obtainium to po prostu kolejny etap ewolucji.