Timothee Ravier di Red Hat, maintainer dei progetti Fedora Silverblue e Fedora Kinoite, ha proposto un metodo per evitare l'uso dello strumento sudo, che utilizza il bit suid per elevare i privilegi. Invece di sudo, per eseguire comandi come utente normale con diritti root, si suggerisce di utilizzare lo strumento ssh con una connessione locale alla stessa sistema tramite socket UNIX e controllo delle autorizzazioni basato su chiavi SSH.
L'uso di ssh invece di sudo consente di eliminare i programmi suid dal sistema e di organizzare l'esecuzione di comandi privilegiati nell'ambiente host delle distribuzioni che utilizzano l'isolamento dei componenti tramite contenitori, come Fedora Silverblue, Fedora Kinoite, Fedora Sericea e Fedora Onyx. Per limitare l'accesso, si può inoltre implementare una conferma delle autorizzazioni tramite token USB (ad esempio, Yubikey).
Esempio di configurazione dei componenti server OpenSSH per l'accesso tramite socket Unix locale (verrà avviata un'istanza separata di sshd con il proprio file di configurazione):
/etc/systemd/system/sshd-unix.socket: [Unit] Description=OpenSSH Server Unix Socket Documentation=man:sshd(8) man:sshd_config(5) [Socket] ListenStream=/run/sshd.sock Accept=yes [Install] WantedBy=sockets.target
/etc/systemd/system/sshd-unix@.service: [Unit] Description=OpenSSH per-connection server daemon (Unix socket) Documentation=man:sshd(8) man:sshd_config(5) Wants=sshd-keygen.target After=sshd-keygen.target [Service] ExecStart=-/usr/sbin/sshd -i -f /etc/ssh/sshd_config_unix StandardInput=socket
/etc/ssh/sshd_config_unix: # Оставляет только аутентификацию по ключам PermitRootLogin prohibit-password PasswordAuthentication no PermitEmptyPasswords no GSSAPIAuthentication no # ограничиваем доступ выбранным пользователям AllowUsers root adminusername # Оставляем только использование .ssh/authorized_keys (без .ssh/authorized_keys2 AuthorizedKeysFile .ssh/authorized_keys # включаем sftp Subsystem sftp /usr/libexec/openssh/sftp-server
Attivare e avviare l'unità systemd: sudo systemctl daemon-reload sudo systemctl enable —now sshd-unix.socket
Aggiungere la propria chiave SSH in /root/.ssh/authorized_keys
Configurare il funzionamento del client SSH.
Installa l'utilità socat: sudo dnf install socat
Completiamo /.ssh/config, specificando socat come proxy per l'accesso tramite UNIX socket: Host host.local User root # Utilizziamo /run/host/run invece di /run per lavorare dai contenitori ProxyCommand socat — UNIX-CLIENT:/run/host/run/sshd.sock # Percorso della chiave SSH IdentityFile ~/.ssh/keys/localroot # Abilitiamo il supporto TTY per la shell interattiva RequestTTY yes # Rimuoviamo output superflui LogLevel QUIET
Nella sua forma attuale, l'utente adminusername ora può eseguire comandi con privilegi di root senza inserire la password. Verifichiamo il funzionamento: $ ssh host.local [root ~]#
Creiamo un alias in bash chiamato sudohost per eseguire «ssh host.local» in modo analogo a sudo: sudohost() { if [[ ${#} -eq 0 ]]; then ssh host.local «cd \»${PWD}\»; exec \»${SHELL}\» —login» else ssh host.local «cd \»${PWD}\»; exec \»${@}\»» fi }
Verifichiamo: $ sudohost id uid=0(root) gid=0(root) groups=0(root)
Aggiungiamo un controllo delle autorizzazioni e abilitiamo l'autenticazione a due fattori, consentendo l'accesso a root solo inserendo il token USB Yubikey.
Verifichiamo quali algoritmi supporta il Yubikey attuale: lsusb -v 2>/dev/null | grep -A2 Yubico | grep «bcdDevice» | awk ‘{print $2}’
Se viene visualizzato un valore di 5.2.3 o superiore, utilizziamo ed25519-sk per la generazione delle chiavi, altrimenti - ecdsa-sk: ssh-keygen -t ed25519-sk oppure ssh-keygen -t ecdsa-sk
Aggiunge la chiave pubblica in /root/.ssh/authorized_keys
Aggiungiamo il vincolo sul tipo di chiave nella configurazione di sshd: /etc/ssh/sshd_config_unix: PubkeyAcceptedKeyTypes sk-ecdsa-sha2-nistp256@openssh.com,sk-ssh-ed25519@openssh.com
Limitiamo l'accesso al socket Unix solo all'utente che può ottenere privilegi elevati (nel nostro esempio - adminusername). In /etc/systemd/system/sshd-unix.socket aggiungiamo: [Socket] … SocketUser=adminusername SocketGroup=adminusername SocketMode=0660
Fonte: opennet.ru
