Выкарыстанне SSH па-над UNIX-сокетам замест sudo для збавення ад suid-файлаў

Цімаці Раўе (Timothee Ravier) з кампаніі 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 [Install] WantedBy=sockets.target

/ і г.д. / systemd / system /[электронная пошта абаронена]: [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: # Пакідае толькі аўтэнтыфікацыю па ключах . 2 AuthorizedKeysFile .ssh/authorized_keys # уключаем sftp Subsystem sftp /usr/libexec/openssh/sftp-server

Актывуем і запускаем юніт systemd: sudo systemctl daemon-reload

Дадаем свой 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 yes # Прыбіраны лішняя выснова LogLevel QUIET

У бягучым выглядзе карыстач adminusername зараз зможа выканаць каманды з правамі root без уводу пароля. Правяраем працу: $ ssh host.local [root ~]#

Ствараем у bash псеўданім sudohost для запуску "ssh host.local" па аналогіі з sudo: sudohost() { if [[ ${#} -eq 0 ]]; then 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 толькі пры ўстаўцы USB-токена Yubikey.

Правяраем, якія алгарытмы падтрымлівае наяўны 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

Дадаць каментар