Timothee Ravier z Red Hat, opiekun projektów Fedora Silverblue i Fedora Kinoite, zaproponował sposób na uniknięcie używania narzędzia sudo, które wykorzystuje bit suid do eskalacji uprawnień. Zamiast sudo, aby zwykły użytkownik mógł wykonywać polecenia z uprawnieniami roota, proponuje się użycie narzędzia ssh z lokalnym połączeniem do tego samego systemu poprzez gniazdo UNIX i weryfikację uprawnień na podstawie kluczy SSH.
Użycie ssh zamiast sudo pozwala pozbyć się programów suid w systemie i umożliwić wykonywanie uprzywilejowanych poleceń w środowisku hosta dystrybucji korzystających z komponentów izolacji kontenerów, takich jak Fedora Silverblue, Fedora Kinoite, Fedora Sericea i Fedora Onyx. Aby ograniczyć dostęp, można dodatkowo zastosować potwierdzenie uprawnień za pomocą tokena USB (np. Yubikey).
Przykład konfiguracji komponentów serwera OpenSSH do dostępu poprzez lokalne gniazdo Unix (zostanie uruchomiona osobna instancja sshd z własnym plikiem konfiguracyjnym):
/etc/systemd/system/sshd-unix.socket: [Unit] Opis=Dokumentacja gniazda Unix serwera OpenSSH=man:sshd(8) man:sshd_config(5) [Socket] ListenStream=/run/sshd.sock Accept=yes [Zainstaluj] WantedBy=sockets.target
/ etc / systemd / system /[email chroniony]: [Jednostka] Opis=Demon serwera połączenia per-połączenia OpenSSH (gniazdo Unix) Dokumentacja=man:sshd(8) man:sshd_config(5) Wants=sshd-keygen.target After=sshd-keygen.target [Usługa] ExecStart=- /usr/sbin/sshd -i -f /etc/ssh/sshd_config_unix StandardInput=gniazdo
/etc/ssh/sshd_config_unix: # Pozostawia tylko uwierzytelnianie kluczem PermitRootLogin zakaz-hasło PasswordAuthentication nie PermitEmptyPasswords no GSSAPIAuthentication no # ogranicza dostęp do wybranych użytkowników Zezwalaj na użytkownika root adminusername # Pozostawia użycie tylko .ssh/authorized_keys (bez .ssh/authorized_keys2 AuthorizedKeysFile .ssh /authorized_ klucze # włącz podsystem sftp sftp /usr/libexec/openssh/sftp-server
Aktywuj i uruchom jednostkę systemową: sudo systemctl daemon-reload sudo systemctl Enable — teraz sshd-unix.socket
Dodaj swój klucz SSH do /root/.ssh/authorized_keys
Konfiguracja klienta SSH.
Zainstaluj narzędzie socat: Sudo dnf install socat
Uzupełniamy plik /.ssh/config, określając socat jako serwer proxy dostępu przez gniazdo UNIX: Host host.local Użytkownik główny # Użyj /run/host/run zamiast /run, aby pracować z kontenerów ProxyCommand socat - KLIENT UNIX: / run/host/run/sshd.sock # Ścieżka do klucza SSH IdentityFile ~/.ssh/keys/localroot # Włącz obsługę TTY dla interaktywnej powłoki RequestTTY tak # Usuń niepotrzebne wyjście LogLevel QUIET
W swojej obecnej formie użytkownik adminusername będzie teraz mógł wykonywać polecenia jako root bez podawania hasła. Sprawdzanie operacji: $ ssh host.local [root ~]#
Tworzymy alias sudohost w bash, aby uruchomić „ssh host.local”, podobnie jak sudo: sudohost() { if [[ ${#} -eq 0 ]]; następnie ssh host.local "cd \"${PWD}\"; exec \"${SHELL}\" --login" else ssh host.local "cd \"${PWD}\"; exec \»${@}\»» fi }
Sprawdź: $ sudohost id uid=0(root) gid=0(root) groups=0(root)
Dodajemy dane uwierzytelniające i włączamy uwierzytelnianie dwuskładnikowe, umożliwiając dostęp do konta root tylko po włożeniu tokena USB Yubikey.
Sprawdzamy, jakie algorytmy obsługuje istniejący Yubikey: lsusb -v 2>/dev/null | grep -A2 Yubico | grep "bcdDevice" | awk '{wydrukuj 2 $}'
Jeśli wynik to 5.2.3 lub nowszy, użyj ed25519-sk podczas generowania kluczy, w przeciwnym razie użyj ecdsa-sk: ssh-keygen -t ed25519-sk lub ssh-keygen -t ecdsa-sk
Dodaje klucz publiczny do /root/.ssh/authorized_keys
Dodaj powiązanie typu klucza do konfiguracji sshd: /etc/ssh/sshd_config_unix: PubkeyAcceptedKeyTypes [email chroniony],[email chroniony]
Ograniczamy dostęp do gniazda Unix tylko do użytkownika, który może mieć podwyższone uprawnienia (w naszym przykładzie adminusername). W pliku /etc/systemd/system/sshd-unix.socket dodaj: [Socket] ... SocketUser=nazwa użytkownika administratora SocketGroup=nazwa użytkownika administratora SocketMode=0660
Źródło: opennet.ru