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
Jest tam też chyba dość sporo sytuacji, gdzie dowolny użytkownik tego systemu może eskalować do roota wynikających z wyścigów na systemie plików.
Np. `useradd` nie jest zbyt ostrożny w tym jak tworzy katalog: https://github.com/shadow-maint/shadow/blob/master/src/useradd.c#L2293. Jeśli użytkownik (którego $HOME nie ma +t) odpali tworzenie użytkownika-cienia, i między między mkdir() z 2365 a chown() z 2387 zmieni nazwę .shadow-home, a na jego miejsce wsadz symlink dokądkolwiek ten chown zmieni właściciela tego symlinka.
Midlaunch odpala `bwrap`a jako root. W związku z tym bind mounty przezeń wykonywane będą używały uprawnień roota do trawersowania katalogów, więc pozwala użytkownikowi podmontować sobie w widocznym miejscu coś z katalogu, w którym on sam nie ma +x. Gdzieś wcześniej sprawdzasz czy właściwy użytkownik ma dostęp, no ale znowu to może być symlink który podmienię pomiędzy tym wywołaniem access a odpaleniem się bbwrapa. (Trochę nie rozumiem, czemu to nie uruchamia bwrapa jako użytkownik-cień.)
Jeśli sysctl protected_hardlinks (https://www.kernel.org/doc/Documentation/sysctl/fs.txt) nie jest włączony, chmid pozwala kraść pliki: można podmienić plik na hardlink do cudzego pliku pomiędzy weryfikacją właściciela a chmodem.
No i jeśli midlaunchowi każe podmontować coś na /sbin/runuser, to on to bardzo chętnie mi odpali jako root.
@robryk Chmid już nie pozwala kraść plików. Nie uruchomi się, jeżeli fs.protected_hardlinks jest wyłączony.
https://git.disroot.org/anedroid/midutils/commit/4c93e3bfe0ce37cc46abbc743709943e3226603e
Wydaje mi się, że podobny mechanizm prewencyjny powinienem zaimplementować przy tworzeniu użytkownika.
@robryk Albo mógłbym tymczasowo zmienić właściciela primary homedir na nobody i dać +t, a potem zmienić go na shadow usera. Myślisz, że to dobry pomysł?
Na pierwszy rzut oka każdy proces który ma wiele faz jest złym pomysłem, bo jest znacznie więcej sytuacji brzegowych do rozważenia (chociażby z powodu obsługi błędów, jak i z powodu możliwych wyścigów między wieloma kopiami tego samego procesu).
Czemu w ogóle kazać `useradd`owi tworzyć katalog domowy? Czemu nie zrobić tego zawczasu?
@robryk Zastanawiam się, czy midsu zadziałałby z ecryptfs - w alt1 pliki shadow usera nie zostałyby zaszyfrowane.
@robryk Która wersja midsu lepsza?
https://git.disroot.org/anedroid/midutils/commit/d7a58eb70a8a95a1d41a838c81512c65d2bbd885
https://git.disroot.org/anedroid/midutils/commit/c0bb74985a700c4c70657d8c3de848bc9893033b
W branch master najpierw zmieniam właściciela primary homedir i ustawiam +s, następnie kopiuję zawartość /etc/skel do .shadow_home. Z kolei w branch alt1 całkowicie przeniosłem homedir shadow usera do /home.
W obydwu wykorzystuję blokadę na pliku /etc/midsu, aby dwie wersje midsu nie mogły operować jednocześnie prowadząc do race condition.