The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Использование SSH поверх UNIX-сокета вместо sudo
Тимоти Равье (Timothee Ravier) из компании Red Hat, мэйнтейнер проектов Fedora
Silverblue и Fedora Kinoite, предложил заслуживающий внимания способ ухода
от применения утилиты sudo, использующей  suid-бит для повышения привилегий.
Вместо sudo для выполнения обычным пользователем команд с правами root
предлагается задействовать утилиту ssh с локальным соединением к той же системе
через UNIX-сокет.

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

Настраиваем серверные компоненты 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



/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


Активируем и запускаем юнит 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 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 sk-ecdsa-sha2-nistp256@openssh.com,sk-ssh-ed25519@openssh.com

Ограничиваем доступ к Unix-сокету только пользователя, которому можно повышать
привилегии (в нашем примере - adminusername). В
/etc/systemd/system/sshd-unix.socket добавляем:

   [Socket]
   ...
   SocketUser=adminusername
   SocketGroup=adminusername
   SocketMode=0660
 
20.12.2023 , Источник: https://tim.siosm.fr/blog/2023/12/1...
Ключи: sudo, ssh, unix, socket, suid / Лицензия: CC-BY
Раздел:    Корень / Безопасность / SSH

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, x3who (?), 12:08, 20/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Как пример того, что вот можно вот так извернуться - интересное.
     
     
  • 2.3, Аноним (3), 15:11, 20/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Позитив в том, что такие штуки возможны, что возможно дорабатывать и менять.

    В остальном, такое себе... Изнутри изолированного потребовались повышенные привилегии, которые потом захочется изолировать, но так, чтобы были повышенные привилегии для ...

     
     
  • 3.6, x3who (?), 16:20, 20/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Позитив в том, что такие штуки возможны, что возможно дорабатывать и менять.

    Именно!

    С ssh там можно накрутить опупенной логики - добавляешь command="скрипт" в .ssh/authorized_keys (пример тут:  https://www.ubuntumint.com/restrict-ssh-user-commands/ ) и этот будет принудительно выполняться. Можно извращаться как по ссылке, можно как-то по-сложному анализировать чо там юзер хотел выполнить и принимать решение нужно ли это выполнять, или выполнить что-то другое, в конце концов можно просто отдельный аудит вести что там вызывали и что возвращено юзеру.

    Но, гонять это всё через сокет и на каждый чих стартовать индивидуальный OpenSSH демон - КМК так себе идея :)

     

  • 1.4, Аноним (3), 15:14, 20/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Как охранять ключ?

    Хэш от пароля хоть лежит в /etc/shadow, туда ещё добраться надо и побрутфорсить после, а ключ валяется под ногами у браузера, у некоторых без пароля.

     
     
  • 2.10, Арчевод (?), 17:55, 20/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Поэтому голый SSH ключ не нужно использовать (как впрочем и для других SSH соединений). Можно настроить пароль/токен/пароль+токен и проблема решена.
     
  • 2.17, Аноним (17), 13:08, 23/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Docume

    Для хранения ключей рекомендуют использовать апаратные ключи безопасности:
    https://www.nitrokey.com/news/2018/nitrokey-partners-linux-foundation-equip-al
    https://www.nitrokey.com/news/2019/nitrokey-partners-gentoo-foundation-equip-d
    https://www.nitrokey.com/news/2021/nitrokey-equips-arch-linux-developers-usb-k

     
  • 2.19, Аноним (19), 09:55, 24/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    можно например защитить его паролем пользователя, а при входе автоматически разблокировать с помощью pam_ssh
     

  • 1.5, Аноним (5), 15:15, 20/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Проблема только в том, что пароль к sudo - в голове у пользователя, а ключ SSH лежит в файле на диске, и процессы, запущенные с правами этого пользователя, имеют права доступа на чтение к нему. Имхо, это ещё менее секьюрно, чем использование suid в sudo.
     
     
  • 2.7, x3who (?), 16:49, 20/12/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Проблема только в том, что пароль к sudo - в голове у
    > пользователя, а ключ SSH лежит в файле на диске, и процессы,
    > запущенные с правами этого пользователя, имеют права доступа на чтение к
    > нему. Имхо, это ещё менее секьюрно, чем использование suid в sudo.

    Второй абзац статьи: "дополнительно может быть задействовано подтверждение полномочий при помощи USB-токена (например, Yubikey)"

     

  • 1.8, Аноним (8), 17:44, 20/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Заслуживающий внимания пример костыля, решающего высосанную из пальца проблему.
    Даем полноценного рута по локальному ссш, потому что боимся, что юзер с судо поднимет привилегии до рута? Я ничего не упускаю?
     
     
  • 2.9, Аноним (8), 17:49, 20/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще, чтобы было совсем красношапково и поттерингоугодно, команды нужно отправлять через сервер красной шапки. Локальный демон от рута читает и выполняет все команды, которые с него приходят. Судо не нужно! Корпоративный контроль над всеми выполняемыми командами!
     
     
  • 3.11, Аноним (11), 17:57, 20/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не корпоративный, а "ориентированный на пользователя (с заботой о пользователе", такой себе ssh-антивирус. Не пропустит злонамеренные команды в шелл!
     

  • 1.12, Аноним (11), 18:00, 20/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > заслуживающий внимания способ ухода

    Очередное "упрощение", которое в итоге выливается во всё бОльшую огороженность системы от модифицирования локальным пользователем (с такими уходами останется одна консоль с клавой и монитором)

     
     
  • 2.15, Kuromi (ok), 18:19, 21/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так логично, идут по пути Андроида. Хотят чтобы никаких рутов и рут доступа к начинке. Софтик вот уже в флатпаках и снапах, по сути, вне классической системы пакетов. Магазинчики приложений красивые для того же делают, чтобы меньше нос совали.
     

  • 1.14, swarus (ok), 14:56, 21/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    примерно так использую
    $ ssh -X secret@localhost torfi firefox-esr
    /home/secret - закриптован
    для скрытого сидения в инете, но sudo не отменяет
     
  • 1.16, Аноним (16), 12:53, 23/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Почему не использовать современную дыру от поцтеринга: dbus+polkit: https://www.linux.org.ru/forum/security/15600248?cid=15601109

    Правельный путь CAP:  https://www.opennet.ru/openforum/vsluhforumID3/132366.html#85

     
  • 1.18, Ph0zzy (ok), 00:30, 24/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А ещё вместо классического ssh, использовать вот этот https://github.com/francoismichel/ssh3
     
  • 1.20, Аноним (20), 22:46, 27/02/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Идея красивая, спору нет. Но во-первых - оверхед (ssh-у нужно как ни крути туда-сюда все шифровать), во-вторых уже помянутая проблема необходимости второго фактора, в-третьих - плюс одна пара токенов, которые нужно менеджить и регулярно ротировать.
     


     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру