Вопрос или проблема
На Linux (в последних версиях) Xorg слушает на сокете домена Unix в файловой системе (/tmp/.X11-unix/X<n>) и в абстрактном пространстве имен (показан как @/tmp/.X11-unix/X<n> в выводе netstat).
Он также слушает на TCP (порт 6000 + <n>).
Его можно заставить не слушать на TCP, добавив -nolisten tcp, но как можно сказать ему, чтобы он не слушал в абстрактном пространстве имен?
Я нашел ответ, пока писал вопрос, так что могу опубликовать оба в случае, если это поможет кому-то.
X -nolisten abstract
принимается, но не работает.
X -nolisten local
похоже, работает. Я ожидал, что это отключит все сокеты домена Unix, но это не так. Это отключает только сокет абстрактного пространства имен.
Как отметил @imz–IvanZakharyaschev, и как подтверждается чтением кода (https://cgit.freedesktop.org/xorg/lib/libxtrans/tree/Xtrans.c?id=c4262efc9688e495261d8b23a12f956ab38e006f#n99 -> https://cgit.freedesktop.org/xorg/lib/libxtrans/tree/Xtranssock.c?id=c4262efc9688e495261d8b23a12f956ab38e006f#n2532), чтобы отключить сокеты домена Unix, нужно использовать -nolisten unix.
Действительно, есть много мест, где Xorg слушает по умолчанию, и довольно сложно отключить некоторые из них. Полный список:
tcpсокеты, вероятно, наиболее небезопасныеabstractсокеты. Эти трудно ограничить в “тюрьмах” пространства имен, например, bubblewrap, и я предполагаю, что flatpak и браузер Chrome тоже.localсокеты- Наконец, стандартный
/tmp/.X11-unix, который, если я правильно понимаю, является именованным каналом. Это наиболее безопасный вариант, так как он не слушает во внешней сети, и очень легко ограничить доступ к нему с помощью стандартных механизмов управления доступом к файловой системе.
Тестирование
Чтобы протестировать, затронута ли ваша система, попробуйте:
ss -l | grep @/tmp/.X11 для абстрактных сокетов, ss -l | grep " /tmp/.X11" для локальных сокетов, ss -l | grep tcp для TCP сокетов, ls -l /tmp для именованных каналов.
Отключение
Если вы хотите отключить сокеты, например, для безопасности, вы можете сделать это.
Для обычного “xinit”: /etc/X11/xinit/xserverrc:
#!/bin/sh
exec unshare -n /usr/bin/X -nolisten tcp -nolisten local "$@"
Для “lightdm”: /etc/lightdm/lightdm.conf.d/50-X-no-listen.conf
[Seat:*]
xserver-command=unshare -n X -nolisten tcp -nolisten local
Предупреждение
Отключение локальных сокетов имеет побочный эффект. Ваши клавиатуры перестанут автоматически определяться при подключении. Я не полностью понял, почему это происходит. Не стесняйтесь обновлять этот ответ, если есть какая-либо ясность по этому поводу или как это обойти. Если клавиатура/мыши (входные устройства в /dev/input/) уже подключены перед запуском экземпляра Xorg, они продолжают нормально работать.
Авторы
https://tstarling.com/blog/2016/06/x11-security-isolation/ (Большое спасибо за это, я взял 50% своего решения оттуда!)
Мое предложение – оставить xserverrc (/etc/X11/xinit) таким:
#!/bin/sh
exec `/usr/bin/X -nolisten tcp -nolisten 'local' "$@"`
(после exec откройте crasis и завершите с crasis тоже).
и для /usr/bin/Xorg, то же самое …
Это потому, что local считается локальной переменной окружения sh/bash/dash/ash, используемой только внутри функций и является зарезервированным словом для этой цели.
Теперь, если вы выполните: $ lsof |grep Xorg |grep -i listen (это больше не вернет @/tmp/.X11-unix/XN)
Ответ или решение
Возможно ли запретить Xorg слушать на абстрактном сокете?
На современных версиях Linux сервер Xorg по умолчанию слушает на нескольких типах сокетов: в файловой системе (например, /tmp/.X11-unix/X<n>) и в абстрактной области (например, @/tmp/.X11-unix/X<n>, как это отображается в выводе netstat). Также он может слушать на TCP-портах (например, на порту 6000 + n).
Отключение TCP-сокетов
Для того чтобы запретить Xorg слушать на TCP, можно воспользоваться параметром -nolisten tcp. Однако вопрос о том, как отключить прослушивание на абстрактном сокете, остается актуальным.
Решение проблемы
Исследовав ситуацию, мы можем воспользоваться параметром командной строки, который предоставляет эту функциональность:
X -nolisten localЭтот параметр очень важен, потому что, хотя он изначально может показаться, что он отключает все сокеты Unix, на самом деле он отключает исключительно абстрактные сокеты, оставляя возможность использования локальных сокетов. Это полезный нюанс, о котором стоит помнить.
Если же вам нужно отключить все сокеты Unix, включая локальные, можно использовать:
X -nolisten unixПроблемы с различными типами сокетов
Xorg может слушать на нескольких типах сокетов, и это может создать уязвимости. Полный список включает:
- TCP-сокеты: являются наиболее уязвимыми.
- Абстрактные сокеты: их сложнее контролировать в ограниченных пространствах имён (например, при использовании bubblewrap).
- Локальные сокеты: уменьшают уровень безопасности.
- Именованные каналы в
/tmp/.X11-unix: наиболее безопасный вариант, так как контролируется стандартными механизмами управления доступом файловой системы.
Тестирование
Чтобы проверить активность сокетов на вашей системе, можно использовать следующие команды:
ss -l | grep @/tmp/.X11 # для абстрактных сокетов
ss -l | grep " /tmp/.X11" # для локальных сокетов
ss -l | grep tcp # для TCP-сокетов
ls -l /tmp # для именованных каналовОтключение сокетов на практике
Если ваша цель — повысить безопасность, вы можете настроить отключение сокетов. Для этого:
- Для
xinit: измените файл/etc/X11/xinit/xserverrcна следующее:
#!/bin/sh
exec unshare -n /usr/bin/X -nolisten tcp -nolisten local "$@"- Для
lightdm: используйте конфигурацию/etc/lightdm/lightdm.conf.d/50-X-no-listen.conf:
[Seat:*]
xserver-command=unshare -n X -nolisten tcp -nolisten localВажные замечания
Следует понимать, что отключение локальных сокетов может привести к тому, что устройства ввода, такие как клавиатуры, не будут автоматически определяться при их подключении. Это происходит из-за особенностей работы Xorg и может потребовать дополнительных настроек.
Заключение
Использование параметров -nolisten local и -nolisten unix позволяет вам более гибко управлять тем, на каких сокетах слушает Xorg, что является важным шагом для повышения безопасности системы. Для оптимизации работы с Xorg рекомендуется внимательно следить за конфигурациями и тестировать их в вашем конкретном окружении.