Usare SSH su un socket UNIX invece di sudo per eliminare i file suid

Timothee Ravier di Red Hat, manutentore dei progetti Fedora Silverblue e Fedora Kinoite, ha proposto un modo per evitare l'uso dell'utilità sudo, che utilizza il bit suid per aumentare i privilegi. Al posto di sudo, per consentire ad un normale utente di eseguire comandi con diritti di root, si propone di utilizzare l'utility ssh con connessione locale allo stesso sistema tramite socket UNIX e verifica dei permessi basata su chiavi SSH.

Usare ssh invece di sudo ti consente di sbarazzarti dei programmi suid sul sistema e abilitare l'esecuzione di comandi privilegiati nell'ambiente host di distribuzioni che utilizzano componenti di isolamento dei contenitori, come Fedora Silverblue, Fedora Kinoite, Fedora Sericea e Fedora Onyx. Per limitare l'accesso è possibile utilizzare anche la conferma dell'autorizzazione mediante un token USB (ad esempio Yubikey).

Un esempio di configurazione dei componenti del server OpenSSH per l'accesso tramite un socket Unix locale (verrà avviata un'istanza sshd separata con il proprio file di configurazione):

/etc/systemd/system/sshd-unix.socket: [Unità] Descrizione=OpenSSH Server Unix Socket Documentation=man:sshd(8) man:sshd_config(5) [Socket] ListenStream=/run/sshd.sock Accept=yes [Installa] WantedBy=sockets.target

/etc/systemd/system/[email protected]: [Unità] Descrizione=Daemon del server OpenSSH per connessione (socket Unix) 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: # Lascia solo l'autenticazione con chiave PermitRootLogin descend-password PasswordAuthentication no PermitEmptyPasswords no GSSAPIAuthentication no # limita l'accesso agli utenti selezionati EnableUsers root adminusername # Lascia solo l'uso di .ssh/authorized_keys (senza .ssh/authorized_keys2 AuthorizedKeysFile .ssh /authorized_keys # abilita il sottosistema sftp sftp /usr/libexec/openssh/sftp-server

Attiva e avvia l'unità systemd: sudo systemctl daemon-reload sudo systemctl abilita —now sshd-unix.socket

Aggiungi la tua chiave SSH a /root/.ssh/authorized_keys

Configurazione del client SSH.

Installa l'utilità socat: sudo dnf install socat

Integriamo /.ssh/config specificando socat come proxy per l'accesso tramite un socket UNIX: Host host.local User root # Usa /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 # Abilita il supporto TTY per la shell interattiva RequestTTY yes # Rimuovi l'output non necessario LogLevel QUIET

Nella sua forma attuale, l'utente adminusername sarà ora in grado di eseguire comandi come root senza inserire una password. Verifica dell'operazione: $ ssh host.local [root ~]#

Creiamo un alias sudohost in bash per eseguire “ssh host.local”, simile a sudo: sudohost() { if [[ ${#} -eq 0 ]]; quindi ssh host.local "cd \"${PWD}\"; exec \"${SHELL}\" --login" else ssh host.local "cd \"${PWD}\"; exec \»${@}\»» fi }

Controlla: $ sudohost id uid=0(root) gid=0(root) groups=0(root)

Aggiungiamo credenziali e abilitiamo l'autenticazione a due fattori, consentendo l'accesso root solo quando viene inserito un token USB Yubikey.

Controlliamo quali algoritmi sono supportati dall'attuale Yubikey: lsusb -v 2>/dev/null | grep -A2 Yubico | grep "bcdDevice" | awk '{stampa $2}'

Se l'output è 5.2.3 o versione successiva, utilizzare ed25519-sk durante la generazione delle chiavi, altrimenti utilizzare ecdsa-sk: ssh-keygen -t ed25519-sk o ssh-keygen -t ecdsa-sk

Aggiunge la chiave pubblica a /root/.ssh/authorized_keys

Aggiungi un'associazione del tipo di chiave alla configurazione sshd: /etc/ssh/sshd_config_unix: PubkeyAcceptedKeyTypes [email protected],[email protected]

Limitiamo l'accesso al socket Unix solo all'utente che può avere privilegi elevati (nel nostro esempio, adminusername). In /etc/systemd/system/sshd-unix.socket aggiungere: [Socket] ... SocketUser=adminusername SocketGroup=adminusername SocketMode=0660

Fonte: opennet.ru

Aggiungi un commento