Зависит ли firejail от сбоя приложения и почему мы не можем использовать именованные каналы для .Xauthority?

The purpose of jailing an Xorg application is to prevent it from accessing @/tmp/X11/X0 and /tmp/X11/X0 and then re-using its MIT-MAGIC-COOKIE to steal from other apps that are connected to the X server

Эм... нет? Если вы читаете, например. это руководство ,

The sandbox replaces the regular X11 server with Xpra or Xephyr server. This prevents X11 keyboard loggers and screenshot utilities from accessing the main X11 server.

Таким образом, цель помещения X-приложения в тюрьму состоит в том, чтобы полностью предотвратить его доступ к основному серверу, а вместо этого позволить ему получить доступ к прокси-серверу. Даже если приложение попытается провернуть прокси-сервер, это не повлияет на основной сервер.

Я не уверен, какой именно сценарий вы описываете, но любое X-приложение, которое каким-то образом имеет доступ к основному серверу, даже если первоначальная авторизация с помощью файлов cookie MIT не выполнялась самим приложением, может затем делать трюки на этом сервере, например регистрация ключей или доступ к другим окнам. Для этого не обязательно падать. Таким образом, первоначальная авторизация для приложения и последующее предотвращение повторной -авторизации никак не помогает.

Возможно, вы упустили из виду, что основная цель запуска помещенного в тюрьму приложения определенным образом заключается в том, чтобы предоставить ему доступ к прокси-серверу X?

Редактировать

I'm just trying to understand what EXACTLY firejail's doing different from traditional xauth/.Xauthority to make the jailed app secure.

Firejail показывает приложению прокси-сервер X-сервера и запрещает приложению доступ к основному X-серверу. Это все. Традиционный механизм xauth абсолютно одинаков как между приложением и X-прокси, так и между X-прокси и основным X-сервером. (И да, конечно X-прокси должен получить доступ к основному серверу, или должна быть программа, которая может получить доступ как к основному X-серверу, так и к X-прокси. Но эти программы являются доверенными , в отличие от приложения ).

and is then relying on Namespaces and to prevent that cookie from being compromised.. and as an added measure hiding the Xorg socket.

Нет. Смысл пространств имен в том, чтобы сделать основные конечные точки связи X-сервера недоступными. Как в "их не существует". На самом деле это не «скрытие» чего-либо («оно есть, но вы его не видите» ). Его больше нет, что касается джейл-приложения. Точно так же контейнер Docker использует пространства имен, чтобы притворяться приложениям в контейнере, что они работают в совершенно другой среде.

Отсутствие того, чтобы заключенное в тюрьму приложение могло видеть конечные точки связи основного X-сервера, уже было бы достаточным, но, конечно, нет никаких причин, по которым заключенное в тюрьму приложение должно видеть действительные файлы cookie MIT для основного X-сервера.

Именованные каналы действительно не имеют к этому никакого отношения. Ни сбоев. Точно так же не работает механизм аутентификации X.

Итак, я отправил электронное письмо в список рассылки Xorg, и они мне очень помогли, вот как все это работает.

Xorg -nolisten tcp -nolisten inet -nolisten inet6 -listen unix -nolisten local :0 -seat seat0 vt7 -novtswitch это команда, которую вы используете для отключения прослушивания, за исключением сокетов домена UNIX (, скопированных из debian ).

Это приведет к созданию /tmp/X11/X0 и @/tmp/X11/X0абстрактных сокетов .

Xorg получает файл cookie по этому каналу/сокету (, написанный программой, использующей Gtk/Qt -->Xlib[.Xauthority])и сравнивает его с предоставленным ему внутренним файлом cookie. по XDM. Если они совпадают, Xorg создаст свой внутренний контекст и свяжет этот контекст с IP-портом :[для соединений tcp/ip] или приложением FD [для сокетов][созданием Named Pipes Socket/FD] 1 .

В основном каждое приложение, записывающее в /tmp/X11/X0, приводит к тому, что Xorg создает уникальный FD в конце. Если приложение умирает и выходит, то этот FD закрывается Xorg, но если приложение внедряется, то этот FD/контекст Xorg НЕ уничтожается, и вирусное/злое -приложение может подделать приложение и продолжить общение с Xorg. Если приложение использует сеть/tcp, то это еще проще, поскольку Xorg просто использует порт IP :для аутентификации после XOpenDisplay/MIT -COOKIE [cookie используется только для одного вызова API к Xorg].

Приложение могло бы, если бы захотело, сохранить COOKIE в своей памяти, что позволило бы хакеру украсть COOKIE, но этот бит аутентификации — работа Xlib. Firejail на самом деле не защищает от кражи файлов cookie. Что он делает, так это использует Xvfb для визуализации графического интерфейса приложения, а затем отправляет растровое изображение на сервер Xorg с помощью Xpra -, который разделен на две части -клиент Xpra и сервер Xpra (Xpra docs/readme объясняет этот бит ).Потому что сервер видит только растровое изображение и не вызывает вызовы API от доверенного -прокси/Xpra -сервера/клиента/от чего бы он ни был защищен своей паранджой и, следовательно, безопасен. Однако насильники все еще бегают, потому что Xorg слабый и жалкий, без какой-либо безопасности :p

Много клейкой -ленты, скрепляющей все это вместе, и это не очень аккуратно и эффективно -, хотя, думаю, это очень спорно. Xorg имеет 0 безопасности, кроме этой одноразовой проверки файлов cookie -, он был разработан для другой эпохи, так что... Пока у меня ничего не работает. Я подозреваю, что будет проще написать сценарий bash для ограничения cgroup/resource -и пространства имен, чем использовать firejail, который использует всевозможные сомнительные хаки и по какой-то причине находится на C. Что касается Xorg... Мне нужно прочитать Xvfb и попытаться извлечь/отправить данные в Xorg через джейл.