Podstawy bezpieczeństwa we FreeBSD

Podstawy bezpieczeństwa we FreeBSD
Instytut Informatyki Uniwersytetu Wrocławskiego
Seminarium: Systemy operacyjne
09.11.2015

Transcript

1. FreeBSD – Podstawy zabezpieczeń Rafał Łasocha II@UWr, 9.11.2015
2. Bezpieczeństwo • bardzo szeroki temat • cross-cutting concern – będziemy przechodzić przez różne części systemu • w tej prezentacji tylko – jak chcemy zabezpieczać SO – Trusted Computing Base (TCB) – izolacja i tożsamość procesów – kontrola dostępu
3. FreeBSD • izolacja jadra i procesów między sobą • uwierzytelnianie, możliwość wielu użytkowników zalogowanych jednocześnie • kontrola dostępu (chmod, chown, …); DAC, MAC • audyt • jails (kontenery) • /dev/random • kryptografia, szyfrowanie dysków • bezpieczne protokoły sieciowe (ssh, TLS)
4. DAC/MAC • Discretionary Access Control – jesteśmy użytkownikiem – więc jesteśmy właścicielami różnych bytów (plików, procesów, …) – chcemy żeby nikt w nie nie ingerował – chcemy dokładnie powiedzieć kto ma jakie dostępy • Mandatory Access Control – jesteśmy administratorem – chcemy żeby w naszym systemie był porządek, nie anarchia – więc chcemy dać możliwość dostępu do pewnych części systemu tylko dla nas
5. Zabezpieczenia procesów (hardware) • pamięć wirtualna • pierścienie (tryb nadzorcy i użytkownika) – przeskakiwanie pomiędzy trybami: wywołania systemowe, przerwania, pułapka pamięci wirtualnej – jadro ma dostęp do wszystkiego (w tym do pamięci wirtualnej procesów użytkownika) • ale proces użytkownika ma już dostęp tylko do swoich zasobów
6. Trusted Computing Base (TCB) • program rozruchowy, jądro, niektóre programy/biblioteki z przestrzeni uzytkownika, np. /sbin/init, /etc/rc.d, /bin/sh, /usr/sbin/sshd, /usr/bin/passwd • wszystkie te pliki mogą być modyfikowane tylko przez roota... przypadek? nie sądzę.
7. Tozsamosc procesu • struct ucred – struct proc i struct thread mają wskaźniki na nią – opisuje „tożsamość” procesu: UID, RUID, GID, dodatkowe grupy, kontener... – fork() dziedziczy tę strukturę – setuid, setgid zmieniają użytkownika (przykłady: logowanie, wysyłanie poczty) – podział na aktualny UID i rzeczywisty UID – możemy chcieć mieć specjalne uprawnienia tylko na początku i na końcu chcemy wrócić do tych samych – „ostatni UID”; exec-normal, exec-setuid – seteuid
8. Model uprawnień • skąd wiemy, że proces może np. zarezerwować port albo załadować moduł jądra? • jak wywołanie systemowe chroot sprawdza czy ten wątek który je wywołał naprawdę ma prawa do zmiany ścieżki roota? • skąd X ma wiedzieć że użytkownik U z kontenera K ma prawo do zrobienia Y?
9. Przywileje niejawne/jawne • jawne – jest gdzieś w kodzie FreeBSD napisane: użytkownik root ma prawo do robienia X, Y, Z...; użytkownik z kontenera ma uprawnienia A, B, C... itd.. • niejawne – rozruch systemu ma pliki konfiguracyjny w /boot – ale właścicielem /boot jest użytkownik root... więc użytkownik /root ma niejawny przywilej do modyfikacji konfiguracji programu rozruchowego
10. Przykładowe przywileje jawne PRIV_REBOOT /* Can reboot system. */ PRIV_SWAPON /* Can swapon(). */ PRIV_CLOCK_SETTIME /* Can call clock_settime. */ PRIV_CRED_SETUID /* setuid. */ PRIV_JAIL_ATTACH /* Attach to a jail. */ PRIV_SCHED_SETPRIORITY /* Can set lower nice value for proc. */ PRIV_SCHED_RTPRIO /* Can set real time scheduling. */ PRIV_SCHED_SETPOLICY /* Can set scheduler policy. */ PRIV_ZFS_POOL_CONFIG /* Can configure ZFS pools. */ PRIV_VFS_MOUNT /* Can mount(). */ PRIV_VFS_STICKYFILE /* Can set sticky bit on file. */ PRIV_NET_SETIFMTU /* Set interface MTU. */ PRIV_NET_SETLLADDR /* Set interface link-level address. */ PRIV_NETBLUETOOTH_RAW /* Open raw bluetooth socket. */ PRIV_NETINET_RESERVEDPORT /* Bind low port number. */
11. chroot /* * Change notion of root (``/'') directory. */ int sys_chroot(struct thread * td, ...flags) { int error; error = priv_check(td, PRIV_VFS_CHROOT); if (error != 0) return (error); // ... }
12. Czas Kodziku sys/kern/kern_priv.c sys/kern/kern_jail.c#prison_priv_check
13. Procesy • … się czasem ze sobą komunikują i coś o sobie wiedzą • co mogą względem siebie robić? • p_cansee, p_cansignal, wait4, debugowanie
14. p_cansee • domyślnie każdy widzi wszystkie procesy w systemie • prywatność? :( • kontenery? :( • priv_check!
15. Czas kodziku • sys/kern/kern_prot.c#1430 • sys/kern/kern_prot.c#1405 • sys/kern/kern_jail.c#prison_check (3498) • sys/kern/kern_prot.c#cr_seeotheruids (1347)
16. Powtórka z SO • r--rwxr-- rafal:students pliczek • Założenie: rafal należy do grupy students • Co mogą robić użytkownicy nie będący studentami? • Co mogą robić studenci? • Co mogę robić ja?
17. Discretionary Access Control • myśl: chmod, chown • obiekty: zwykłe pliki, katalogi, urządzenia, semafory, kolejki... • kolejność: właściciel, grupa, pozostali • problem: zbyt proste uprawnienia – POSIX.1e, NFSv4 – UFS: Unix, POSIX.1e, NFSv4 – ZFS: Unix, NFSv4 – Linux wspiera POSIX.1e, ma też eksperymentalne wsparcie dla NFSv4 dla ext3/4 (źródło: wikipedia)
18. Uprawnienia VFS VEXEC /* execute/search permission */ VWRITE /* write permission */ VREAD /* read permission */ VADMIN /* being the file owner */ VAPPEND /* permission to write/append */ VREAD_ATTRIBUTES /* permission to stat(2) */ VWRITE_ATTRIBUTES /* change {m,c,a}time */ VREAD_ACL /* read ACL and file mode */ VWRITE_ACL /* change ACL and/or file mode */ VWRITE_OWNER /* change file owner */ VCREAT /* creating new file */ ...
19. Uprawnienia UNIX VEXEC = S_IXUSR, S_IXGRP, S_IXOTH VADMIN = właściciel pliku VAPPEND = S_IWUSR, S_IWGRP, S_IWOTH VREAD_ATTRIBUTES = zawsze dozwolone VWRITE_ATTRIBUTES = zmapowane na VADMIN
20. Algorytm UNIX • pobieramy UID procesu – jeśli UID == właściciel, to sprawdzamy jego uprawnienia – jeśli nie, to priv_check • pomyśl o pliku, którego właścicielem jest rafal, a root chce się do niego dostać • następnie analogicznie sprawdzamy grupę • a na końcu pozostałych
21. Access Control Lists (ACL) • funkcje do zarządzania listami: __acl_get_fd (wyciągnij ACL), __acl_delete_fd (usuń ACL), … • teoretycznie model otwarty na rozbudowy, wystarczy napisać własną funkcję vaccessx
22. POSIX.1e • UNIX: właściciel, grupa, pozostali • POSIX: właściciel, dodatkowy użytkownik, grupa, dodatkowa grupa, pozostali, maska • maska – nakładana na dodatkowych użytkowników i grupy
23. Algorytm POSIX.1e • intuicyjnie podobny do UNIXowego • najpierw sprawdzamy właściciela (z taką samą „procedurą” jak w modelu UNIXowym) • następnie szukamy UID wśród użytkowników dodatkowych • potem grupy – tutaj zachowujemy się odrobinę inaczej – wystarczy dowolna grupa dająca nam uprawnienia które chcemy • na końcu pozostali
24. Pytania?