Timothee Ravier da Red Hat, mantenedor dos projetos Fedora Silverblue e Fedora Kinoite, propôs uma maneira de evitar o uso do utilitário sudo, que usa o bit suid para escalar privilégios. Em vez de sudo, para um usuário normal executar comandos com direitos de root, propõe-se usar o utilitário ssh com conexão local ao mesmo sistema através de um soquete UNIX e verificação de permissões com base em chaves SSH.
Usar ssh em vez de sudo permite que você se livre de programas suid no sistema e habilite a execução de comandos privilegiados no ambiente host de distribuições que usam componentes de isolamento de contêiner, como Fedora Silverblue, Fedora Kinoite, Fedora Sericea e Fedora Onyx. Para restringir o acesso, a confirmação de autoridade usando um token USB (por exemplo, Yubikey) também pode ser usada.
Um exemplo de configuração de componentes do servidor OpenSSH para acesso através de um soquete Unix local (uma instância sshd separada será iniciada com seu próprio arquivo de configuração):
/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 [Instalar] WantedBy=sockets.target
/ etc / systemd / system /[email protegido]: [Unidade] Descrição=daemon de servidor por conexão OpenSSH (soquete Unix) Documentação=man:sshd(8) man:sshd_config(5) Wants=sshd-keygen.target After=sshd-keygen.target [Serviço] ExecStart=- /usr/sbin/sshd -i -f /etc/ssh/sshd_config_unix StandardInput=socket
/etc/ssh/sshd_config_unix: # Deixa apenas a autenticação de chave PermitRootLogin proibido-senha PasswordAuthentication no PermitEmptyPasswords no GSSAPIAuthentication não # restringe o acesso a usuários selecionados AllowUsers root adminusername # Deixa apenas o uso de .ssh/authorized_keys (sem .ssh/authorized_keys2 AuthorizedKeysFile .ssh /authorized_keys # habilita o subsistema sftp sftp /usr/libexec/openssh/sftp-server
Ative e inicie a unidade systemd: sudo systemctl daemon-reload sudo systemctl enable —now sshd-unix.socket
Adicione sua chave SSH a /root/.ssh/authorized_keys
Configurando o cliente SSH.
Instale o utilitário socat: sudo dnf install socat
Complementamos /.ssh/config especificando socat como um proxy para acesso através de um soquete UNIX: Host host.local Usuário root # Use /run/host/run em vez de /run para trabalhar a partir de contêineres ProxyCommand socat - UNIX-CLIENT: / run/host/run/sshd.sock # Caminho para a chave SSH IdentityFile ~/.ssh/keys/localroot # Habilita suporte TTY para o shell interativo RequestTTY yes # Remove saída desnecessária LogLevel QUIET
Em sua forma atual, o usuário adminusername agora poderá executar comandos como root sem inserir uma senha. Verificando a operação: $ ssh host.local [root ~]#
Criamos um alias sudohost no bash para executar “ssh host.local”, semelhante ao sudo: sudohost() { if [[ ${#} -eq 0 ]]; então ssh host.local "cd \"${PWD}\"; exec \"${SHELL}\" --login" else ssh host.local "cd \"${PWD}\"; exec \»${@}\»»fi }
Verifique: $ sudohost id uid=0(root) gid=0(root) groups=0(root)
Adicionamos credenciais e habilitamos a autenticação de dois fatores, permitindo acesso root somente quando um token USB Yubikey é inserido.
Verificamos quais algoritmos são suportados pelo Yubikey existente: lsusb -v 2>/dev/null | grep -A2 Yubico | grep "bcdDevice" | awk '{imprimir $2}'
Se a saída for 5.2.3 ou superior, use ed25519-sk ao gerar chaves, caso contrário, use ecdsa-sk: ssh-keygen -t ed25519-sk ou ssh-keygen -t ecdsa-sk
Adiciona a chave pública a /root/.ssh/authorized_keys
Adicione uma ligação de tipo de chave à configuração sshd: /etc/ssh/sshd_config_unix: PubkeyAcceptedKeyTypes [email protegido],[email protegido]
Restringimos o acesso ao soquete Unix apenas ao usuário que pode ter privilégios elevados (em nosso exemplo, adminusername). Em /etc/systemd/system/sshd-unix.socket adicione: [Socket] ... SocketUser=adminusername SocketGroup=adminusername SocketMode=0660
Fonte: opennet.ru