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.
BTW. Przed kilkoma innymi uchroniło Cię to, że bwrap zawsze ustawia no_new_privs (https://man7.org/linux/man-pages/man2/prctl.2.html) nawet jak nie musi. To też powoduje, że w środku tego co zostanie odpalone przez midlaunch bity SUID i SGID oraz file capabilities nie są respektowane, więc np. `ping` nie będzie działał.
@robryk Hmm, u mnie jakoś ping działa, ale sudo już nie. I ping nie ma u mnie cap_net_raw. Widziałem go natomiast na innej dystrybucji.
Wiem, że brak tej flagi przysporzyłby mi dodatkowych problemów. Jednocześnie, to zmusza mnie do uruchamiania bwrap jako root - nie widzę innego sposobu, jak potem przelogować się na primary user.
TIL o pingu: https://unix.stackexchange.com/questions/592911/how-does-ping-work-on-fedora-without-setuid-and-capabilities
Ta flaga == no_new_privs?
Co najmniej dla rzeczy z run_as_shadow możesz zrobić to w odwrotnej kolejności. (Trochę nie rozumiem, do czego służa aplikacje bez run_as_shadow.)
@robryk Run_as_shadow zostało dodane później. Oryginalnie miało być tak, że aplikacja uruchamia się jako primary user, ale ma pomontowane w sandboxie niektóre foldery z shadow home (de facto należące do primary user, ale primary user nie ma do nich dostępu bo blokuje brak uprawnień grupy dla .shadow-home. Dostęp przez sandboxowaną aplikację do innych katalogów nieustawionych w konfiguracji jest efektem niepożądanym. Innymi słowy, ustawienie run_as_shadow=true to odpowiednik midsu z customowym shellem.
