Using SSH over a UNIX socket instead of sudo to eliminate suid files

Timothee Ravier from Red Hat, maintainer of Fedora Silverblue and Fedora Kinoite projects, proposed a method to avoid using the sudo utility, which employs the suid bit for privilege escalation. Instead of sudo, it is suggested to use the ssh utility with a local connection to the same system via a UNIX socket and credential verification based on SSH keys for executing commands as root by a regular user.

Using ssh instead of sudo allows eliminating suid programs in the system and enables the execution of privileged commands in the host environment of distributions that utilize container isolation of components, such as Fedora Silverblue, Fedora Kinoite, Fedora Sericea, and Fedora Onyx. To restrict access, additional credential verification may be implemented using a USB token (for example, Yubikey).

Example configuration of OpenSSH server components for access through a local Unix socket (a separate instance of sshd will be started with its configuration file):

/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

Activate and start the systemd unit: sudo systemctl daemon-reload sudo systemctl enable --now sshd-unix.socket

Add your SSH key to /root/.ssh/authorized_keys

Configure the SSH client's functionality.

Install the socat utility: sudo dnf install socat

Append to /.ssh/config, specifying socat as a proxy for access through the UNIX socket: Host host.local User root # Use /run/host/run instead of /run for operation from containers ProxyCommand socat -- UNIX-CLIENT:/run/host/run/sshd.sock # Path to the SSH key IdentityFile ~/.ssh/keys/localroot # Enable TTY support for interactive shell RequestTTY yes # Suppress excess output LogLevel QUIET

In its current form, the user adminusername can now execute commands as root without entering a password. Testing the operation: $ ssh host.local [root ~]#

Create a bash alias sudohost to run "ssh host.local" similar to sudo: sudohost() { if [[ \\$# -eq 0 ]]; then ssh host.local "cd \"${PWD}\"; exec \"${SHELL}\" --login" else ssh host.local "cd \"${PWD}\"; exec \"${@}\"" fi }

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

Add credential verification and enable two-factor authentication, allowing root access only with the insertion of a Yubikey USB token.

Check which algorithms are supported by the existing Yubikey: lsusb -v 2>/dev/null | grep -A2 Yubico | grep "bcdDevice" | awk '{print $2}'

If 5.2.3 or a higher value is displayed, use ed25519-sk when generating keys; otherwise, use ecdsa-sk: ssh-keygen -t ed25519-sk or ssh-keygen -t ecdsa-sk

Adds the public key to /root/.ssh/authorized_keys

Adding key type binding to sshd configuration: /etc/ssh/sshd_config_unix: PubkeyAcceptedKeyTypes sk-ecdsa-sha2-nistp256@openssh.com,sk-ssh-ed25519@openssh.com

Restrict access to the Unix socket to the user who can escalate privileges (in our example — adminusername). In /etc/systemd/system/sshd-unix.socket add: [Socket] … SocketUser=adminusername SocketGroup=adminusername SocketMode=0660

Source: opennet.ru

Buy reliable website hosting with DDoS protection, VPS VDS servers 🔥 Buy reliable website hosting with DDoS protection, VPS VDS servers | ProHoster