Bardzo bym prosił o audyt mojego projektu "midutils". Są to 3 małe programy w Pythonie, których zadaniem jest ochrona plików przed nieuprzywilejowanymi procesami, np. plików cookies w Firefoxie, kluczy SSH, ważnych dokumentów. W szczególności zależy mi na ostatnim narzędziu "midlaunch" uruchamiającym aplikacje w kontenerach bwrap, które jest najbardziej złożone (407 linijek kodu). Wszystkie programy wymagają uprawnień root, więc niedopatrzenia mogą prowadzić do nieautoryzowanej eskalacji uprawnień.

Uważam, że w ekosystemie GNU/Linuxa brakuje tego typu narzędzi, więc zrobiłem własne. Chciałbym aby kiedyś trafiło do repozytoriów Arch, Ubuntu, Fedory i innych dystrybucji i pomogło poprawić bezpieczeństwo użytkowników desktopowego GNU/Linuxa. Niestety nie mam zbyt dużego doświadczenia w pracy nad średnimi i dużymi projektami, dlatego proszę was o pomoc.

Link do repozytorium git: https://git.disroot.org/anedroid/midutils

#python #linux #security

@anedroid opisz proszę przed jakimi napastnikami to ma chronić

@robryk Cały system korzysta z dodatkowego konta użytkownika przypisanego do podstawowego - jest to tzn. "shadow user" i ma na celu ochronę wybranych plików przed dostępem przez inne programy uruchamiane jako "primary user" (podstawowe konto z którego korzysta się na co dzień).

Midlaunch uruchamia aplikacje w kontenerach bwrap. Użytkownik może skonfigurować punkty montowania wskazujące na pliki do których ma dostęp shadow user, niekoniecznie zaś primary user. W ten sposób wybrane aplikacje będą uruchamiane jako primary user, ale z dostępem do wybranych chronionych katalogów.

Midsu pozwala tymczasowo zalogować się jako shadow user, w celu zarządzania chronionymi plikami lub zmiany konfiguracji kontenerów.

Chmid jest poleceniem zmieniającym właściciela pliku.

Z wszystkich tych narzędzi można korzystać jako nieuprzywilejowany użytkownik. Nie trzeba nawet być w grupie sudo/wheel. O ile nie jest to zablokowane w /etc/midsu, wywołanie "midsu" powoduje automatyczne utworzenie shadow usera i powiązanie go z kontem, jeśli jeszcze nie istnieje.

@anedroid nie chodzi mi o to jak działa, ale o opis tego skąd napastnik zaczyna i jakiego celu ma nie móc osiągnąć, który normalnie może.

Jeśli napastnik zaczyna z możliwości wykonywania kodu jako podstawowy użytkownik, to czemu np. nie może wsadzić do $PATH katalog ze złośliwym midsu, które następnym razem gdy je uruchomisz wyśle mu wszystkie dane z konta-cienia?

@robryk Zakładamy, że napastnik uzyskuje dostęp do podstawowego użytkownika, nie ma jednak dostępu do konta root. To może się zdarzyć, gdy np. użytkownik uruchomi złośliwy AppImage. Zakładamy również, że midsu jest zainstalowany jako aplikacja systemowa, zatem użytkownik nie może bezpośrednio modyfikować skryptów w /usr/lib/midsu. Te skrypty uzyskują uprawnienia root uruchamiając same siebie z sudo, a konfiguracja sudoers pozwala każdemu użytkownikowi uruchamiać je jako root (przy midsu dodatkowo wymagane jest podanie hasła). Podmiana midsu w $PATH nie zadziałałaby, ponieważ midsu nie miałby jak uruchomić się jako root, a tym samym nie uzyskałby dostępu do chronionych danych.

Chyba, że użytkownik należy do grupy sudo/wheel, wtedy w momencie gdy fałszywy midsu uruchomi się z sudo, użytkownik poda hasło i da fałszywemu midsu dostęp do roota. Niestety nie widzę sposobu w jaki możnaby temu przeciwdziałać, tzn. aby użytkownik mógł rozróżnić fałszywy midsu od prawdziwego. Może jedynie sprawdzić $PATH lub uruchomić midsu po ścieżce /usr/bin/midsu.

Na szczęście midsu jest używany tylko do zarządzania kontenerami (jak su do zarządzania systemem). Pozostałe 2 komendy - chmid oraz najczęściej używany midlaunch, nie wymagają podania hasła. Monit o hasło powinien wzbudzić wątpliwości.