SELinux resetuje hasło roota

Oświadczenie: To pytanie nie ma na celu rozwiązania problemu zmiany hasła roota, gdy SELinux jest aktywny, ponieważ istnieje wiele przewodników, aby to rozwiązać. Jest to bardziej sposób, w jaki SELinux robi to wewnętrznie.

Jestem niedawnym użytkownikiem SELinuksa, ale ostatnio miałem z nim więcej kontaktu. Był moment, kiedy ktoś zapytał mnie, jak mogę zresetować hasło roota w przypadku jego zapomnienia.

Uruchomiłem więc CentOS, zredagowałem wpis gruba do czegoś takiego

linux16 <kernel_location> root=/dev/mapper/centos-root rw init=/bin/bash

Pobiegłem, passwda potem pobiegłem synci wymusiłem ponowne uruchomienie. Po ponownym uruchomieniu logowanie przy użyciu nowego hasła zostało odrzucone, a także przy użyciu starego, oczywiście.

Zrestartowano ponownie i przekazano jądro parametr do wyłączenia SELinux ( selinux=0). Próbowałem zalogować się przy użyciu nowego hasła i zadziałało. Następnie wymusiłem automatyczne ponowne etykietowanie fs (przez plik .autorelabel), a przy aktywnym SELinux można było się zalogować.

Moje pytanie brzmi: dlaczego tak się dzieje? Dlaczego ponowne etykietowanie wpływa na logowanie, gdy nastąpiła jedynie zmiana hasła, a nie użytkowników lub obiektów?

Dziękuję za uwagę.

TL; DR: Zwykłe resetowanie hasła roota nie działa w SELinux. Dlaczego?

Edycja: Zostało to przetestowane na maszynie wirtualnej z systemem CentOS7 z KVM jako hypervisor.

— Jorge Heleno
źródło

Jesteś pewien, że to nie działa? Spróbuj ponownie. Prawdopodobnie będzie działać dobrze. Podejrzewam, że po prostu miałeś niewłaściwe konteksty plików w niektórych plikach, co spowodowało niepowodzenie logowania. Tak więc autorelabel był tym, co naprawdę naprawiło problem.

— Michael Hampton

@MichaelHampton Właśnie odtworzyłem wszystkie moje kroki, robiąc to ponownie, i nie mogłem się ponownie zalogować przy aktywnym SELinux. Po wyłączeniu mogłem zalogować się bez problemu. Popraw mnie, jeśli się mylę, ale zmiana hasła nie powinna zmieniać kontekstów plików, prawda?

— Jorge Heleno

Nie, nie powinno. Wydaje się, że odkryłeś coś dziwnego i nieoczekiwanego.

— Michael Hampton

Udało mi się zduplikować ten problem w świeżo zainstalowanym systemie CentOS 7.5.

Oto co się dzieje:

Podczas uruchamiania init=/bin/bashwystępują dwa problemy, które mogą wystąpić:

Główny system plików może być montowany tylko do odczytu. W takim przypadku passwdreklamuje się Authentication token manipulation error.

Jest to dość oczywiste: jeśli system plików nie jest zamontowany do odczytu i zapisu, nie można do niego pisać.
Polityka SELinux może nie zostać załadowana. W takim przypadku passwdz powodzeniem zmienisz hasło, ale będziesz miał problem opisany w pierwotnym pytaniu powyżej: nikt nie będzie mógł się zalogować.

Skróty hasła są przechowywane w /etc/shadowpliku. Ten plik zwykle ma typ SELinux shadow_t. Jednak zmiana pliku, gdy nie są załadowane żadne zasady SELinux, powoduje usunięcie typu SELinux z pliku, pozostawiając go jako unlabeled_t. Dlatego usługi, które próbują odczytać plik w celu uwierzytelnienia logowania, nie są już w stanie go odczytać.

Aby zmienić hasło roota w RHEL / CentOS 7, musisz wykonać ten proces:

Dodaj init=/bin/bashna końcu wiersza poleceń jądra w grub, tak jak poprzednio.
Po znaku zachęty załaduj politykę SELinux za pomocą /usr/sbin/load_policy -i.
Zamontuj główny system plików w trybie do odczytu i zapisu mount -o remount,rw /.
Teraz zmień hasło, a się powiedzie. passwd root
Zamontuj system plików tylko do odczytu, aby zatwierdzić zmiany i mieć czysty system plików przy następnym uruchomieniu mount -o remount,ro /.
Wyjdź z powłoki lub zrestartuj system za pomocą exec /sbin/init 6.

Teraz możesz zalogować się przy użyciu zmienionego hasła roota.

Dłuższe wyjaśnienie tej procedury jest dostępny z Red Hat (wymagana subskrypcja).

— Michael Hampton
źródło

Problem dotyczył zasad, które nie zostały załadowane. Dlaczego się nie ładują? SELinux powinien działać na poziomie jądra, więc system init nie powinien być wymagany.

— Jorge Heleno

@JorgeHeleno SELinux jest rzeczywiście domyślnie włączony lub wyłączony podczas uruchamiania jądra, ale to użytkownik jest odpowiedzialny za decyzję, które polityki są ładowane. Jądro nie mogło o tym zadecydować, ponieważ niektóre instalacje mogą wymagać różnych zasad (np. Ukierunkowane, ścisłe, mls). Dzieje się tak na początku procesu rozruchu, ale można go obejść podczas uruchamiania init=/bin/bash.

— Michael Hampton

jeśli polityka nie jest załadowana, dlaczego passwd„wydaje się, że się powiodło”?

— Andrew Savinykh,

a jeśli się nie udało, dlaczego logowanie przy użyciu starego hasła nadal nie powiodło się?

— Wyścigi lekkości na orbicie

@Jorge Helen: Twoje wyjaśnienie jest prawie kompletne. Chodzi o pliki zmienione passwdmianowicie /etc/passwdi /etc/shadow. Jeśli działa passwdbez załadowanej polityki, nie działa we właściwym kontekście selinux, a zmienione pliki mają inny kontekst selinux. Podczas uruchamiania z włączonym selinux i aktywnymi zasadami sprawdzanie hasła kończy się niepowodzeniem z powodu niewłaściwego kontekstu pliku, a nie z powodu wrong passwordbłędu. Zmuszenie selinux do odtwarzania tekstowych plików tekstowych poprzez dotknięcie /.autorelabelmoże również rozwiązać ten problem przy zmianie haseł bez załadowanej polityki.

— hargut