Използване на SSH през UNIX сокет вместо sudo, за да се отървете от suid файлове

Тимъти Равиер от Red Hat, поддържащ проектите Fedora Silverblue и Fedora Kinoite, предложи начин да се избегне използването на помощната програма sudo, която използва бита suid за ескалиране на привилегии. Вместо sudo, за нормален потребител да изпълнява команди с права на root, се предлага да се използва помощната програма ssh с локална връзка към същата система чрез UNIX сокет и проверка на разрешения въз основа на SSH ключове.

Използването на ssh вместо sudo ви позволява да се отървете от suid програмите в системата и да разрешите изпълнението на привилегировани команди в хост средата на дистрибуции, които използват компоненти за изолиране на контейнери, като Fedora Silverblue, Fedora Kinoite, Fedora Sericea и Fedora Onyx. За ограничаване на достъпа може допълнително да се използва потвърждение на правомощия с помощта на USB токен (например Yubikey).

Пример за конфигуриране на сървърни компоненти на OpenSSH за достъп през локален Unix сокет (ще бъде стартирано отделно sshd копие със собствен конфигурационен файл):

/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 [Инсталиране] WantedBy=sockets.target

/ И т.н. / systemd / система /[имейл защитен]: [Unit] Description=OpenSSH сървър демон за всяка връзка (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=сокет

/etc/ssh/sshd_config_unix: # Оставя само удостоверяване на ключ PermitRootLogin prohibit-password PasswordAuthentication не PermitEmptyPasswords не GSSAPIAuthentication не # ограничава достъпа до избрани потребители AllowUsers root adminusername # Оставя само използването на .ssh/authorized_keys (без .ssh/authorized_keys2 Автор izedKeysFile .ssh /authorized_ keys # enable sftp Subsystem sftp /usr/libexec/openssh/sftp-сървър

Активирайте и стартирайте модула systemd: sudo systemctl daemon-reload sudo systemctl enable —now sshd-unix.socket

Добавете своя SSH ключ към /root/.ssh/authorized_keys

Настройка на SSH клиента.

Инсталирайте помощната програма socat: sudo dnf install socat

Допълваме /.ssh/config, като посочваме socat като прокси за достъп през UNIX сокет: Host host.local User root # Използвайте /run/host/run вместо /run за работа от контейнери ProxyCommand socat - UNIX-CLIENT: / run/ host/run/sshd.sock # Път до SSH ключа IdentityFile ~/.ssh/keys/localroot # Активиране на TTY поддръжка за интерактивната обвивка RequestTTY да # Премахване на ненужния изход LogLevel QUIET

В сегашната си форма потребителят adminusername вече ще може да изпълнява команди като root, без да въвежда парола. Проверка на операцията: $ ssh host.local [root ~]#

Създаваме псевдоним на sudohost в bash, за да стартираме “ssh host.local”, подобно на sudo: sudohost() { if [[ ${#} -eq 0 ]]; след това ssh host.local "cd \"${PWD}\"; exec \"${SHELL}\" --login" else ssh host.local "cd \"${PWD}\"; exec \»${@}\»» fi }

Проверете: $ sudohost id uid=0(root) gid=0(root) groups=0(root)

Добавяме идентификационни данни и активираме двуфакторно удостоверяване, което позволява root достъп само когато е поставен Yubikey USB токен.

Проверяваме кои алгоритми се поддържат от съществуващия Yubikey: lsusb -v 2>/dev/null | grep -A2 Yubico | grep "bcdDevice" | awk '{print $2}'

Ако изходът е 5.2.3 или по-висок, използвайте ed25519-sk, когато генерирате ключове, в противен случай използвайте ecdsa-sk: ssh-keygen -t ed25519-sk или ssh-keygen -t ecdsa-sk

Добавя публичния ключ към /root/.ssh/authorized_keys

Добавете свързване на тип ключ към конфигурацията на sshd: /etc/ssh/sshd_config_unix: PubkeyAcceptedKeyTypes [имейл защитен],[имейл защитен]

Ние ограничаваме достъпа до Unix сокета само до потребителя, който може да има повишени привилегии (в нашия пример, adminusername). В /etc/systemd/system/sshd-unix.socket добавете: [Socket] ... SocketUser=adminusername SocketGroup=adminusername SocketMode=0660

Източник: opennet.ru