Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Podstawy bezpieczeństwa we FreeBSD

Podstawy bezpieczeństwa we FreeBSD

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

Rafał Łasocha

November 09, 2015
Tweet

More Decks by Rafał Łasocha

Other Decks in Programming

Transcript

  1. FreeBSD – Podstawy zabezpieczeń
    Rafał Łasocha
    II@UWr, 9.11.2015

    View full-size slide

  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

    View full-size slide

  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)

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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ę.

    View full-size slide

  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

    View full-size slide

  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?

    View full-size slide

  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

    View full-size slide

  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. */

    View full-size slide

  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);
    // ...
    }

    View full-size slide

  12. Czas Kodziku
    sys/kern/kern_priv.c
    sys/kern/kern_jail.c#prison_priv_check

    View full-size slide

  13. Procesy

    … się czasem ze sobą komunikują i coś o
    sobie wiedzą

    co mogą względem siebie robić?

    p_cansee, p_cansignal, wait4, debugowanie

    View full-size slide

  14. p_cansee

    domyślnie każdy widzi wszystkie procesy w
    systemie

    prywatność? :(

    kontenery? :(

    priv_check!

    View full-size slide

  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)

    View full-size slide

  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?

    View full-size slide

  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)

    View full-size slide

  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 */
    ...

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide