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
@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.
echo > ~/midsu << EOF
#!/bin/bash
exec /usr/bin/midsu zrób_coś_złośliwego
EOF
chmod +x ~/midsu
echo 'export PATH=$HOME:$PATH' >> ~/.bashrc
@robryk To nie zadziała. Midsu nie pozwala dostosować uruchamianego programu z poziomu linii poleceń. Użytkownik może zmienić domyślny program umieszczając plik wykonywalny .midsu w katalogu domowym shadow usera. Może również wstawić parametr --failsafe aby uruchomić /bin/bash.
> Może również wstawić parametr --failsafe aby uruchomić /bin/bash.
No to atakujący też może to zrobić i poprzekierowywać stdio tego basha.
Jestem silnie przekonany, ze z midlaunch da sie zrobic cos moralnie ekwiwalentnego, ale bede mial czas dopiero wieczorem.
@robryk Faktycznie, zadziałało. Myślę, że można by wyłączyć midsu z $PATH i wymusić wpisywanie /usr/bin/midsu, albo... ustawić .bashrc, .bash_profile i .profile jako read-only:
$ chmod 644 ~/.bashrc ~/.bash_profile ~/.profile
$ chmid upgrade ~/.bashrc ~/.bash_profile ~/.profile
W ten sposób atakujący nie będzie mógł manipulować zmiennymi środowiskowymi. Trzeba by podobnie zrobić z konfiguracją emulatora terminala, aby nie podmienić powłoki tam.
A skad wiesz, ze odpalasz ten emulator terminala (ze nie podmienilem konfiguracji menu twojego srodowiska graficznego, zeby odpalal cos zlosliwego zamiast niego)? A skad wiesz, ze twoj caly window manager nie zostal podmieniony na cos zlosliwego (przez np. ~/.xsession)?
@robryk Hmm, a jakie zabezpieczenia stosuje sudo?
@anedroid Żadne skuteczne (cała zabawa w to, że wpisanie hasła jest "ważne" tylko w tym samym terminalu niewiele daje).
Model w którym wymaganie hasła w sudo w czymkolwiek pomaga to model, w którym ofiara jest nieaktywna (a więc sama nie używa sudo) po tym jak napastnik uzyskał dostęp (no i przed tym jak został wykryty).
@robryk Zaktualizowałem README o sekcję dotyczącą bezpiecznego uruchamiania midsu.
@robryk Ustawiłem tmux jako domyślną powłokę. Jeżeli nie jest zainstalowana, zostanie użyty bash lub sh.
@robryk Dodałem opcje run_as_shadow i permit_args. Teraz można zastąpić midsu midlaunch, pominąć wpisywanie hasła, a z midsu korzystać tylko w ostateczności (jak się coś zepsuje).
[elevated-shell]
Exec = /usr/bin/x-terminal-emulator
Run_as_shadow = true
Permit_args = false
Wydaje mi sie, ze to co robisz tym plikom nie zapobiega zrobieniu `mv ~/.bashrc ~/.smietnik`
@robryk A na to też znalazłem rozwiązanie:
$ chmod +t ~
$ chmid upgrade ~
Mój home dir należy do shadow usera i ma sticky bit. Nie mogę usuwać ani przenosić "niemoich" plików.
$ chmod 644 ~/.bashrc ...
$ chmid upgrade ~/.bashrc ...
No ale teraz masz zatrzęsienie innych plików konfiguracyjnych, które intencjonalnie pozwalają na coś podobnego: .xsession pozwala uruchomić inny window manager (i normalnie nie istnieje), pliki konfigurujące twoje środowisko graficzne pozwalają zmienić to co się odpala jak klikniesz "terminal" (i raczej chcesz je móc edytować, bo typowe środowiska graficzne to robią).
Napastnik może też zostawić uruchomiony program, który będzie ptrace()ował twoje shelle albo który, gdy zostanie odpalony terminal, zabije go i odpali od razu złośliwy terminal.
@anedroid I tego rodzaju rzeczom się _nie da_ przeciwdziałać. Jeśli atakujący ma kontrolę nad tym kawałkiem środowiska, przez które dokonujesz wszystkich swoich interakcji, to może je dowolnie zmieniać i podglądać.