LINUX.ORG.RU

Тормоза Firefox под Firejail в Wayland

 , , ,


0

2

В Xorg работает все отменно, в Wayland лиса ведет себя очень странно, а именно - немного анимация притормаживает когда между вкладками мышку перемещаю. В ютубе все видосы дико тормозят до момента пока я не разверну видео на весь экран. Долго не мог понять в чем дело, пока не запустил Firefox без Firejail. Сразу стал летать! Вывод - дело в правилах firejail. Напомню, что в Xorg с Firefox через firejail таких проблем не наблюдается, значит дело в каких-то специфических правилах для Wayland.

Конфиги профилей скидывать не вижу смысла, т.к. они стандартые и я их не менял.

Высер примерно такой:

$ firejail firefox
Reading profile /home/user/.config/firejail/firefox.profile
Reading profile /etc/firejail/whitelist-usr-share-common.inc
Reading profile /etc/firejail/firefox-common.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-exec.inc
Reading profile /etc/firejail/disable-interpreters.inc
Reading profile /etc/firejail/disable-proc.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/whitelist-common.inc
Reading profile /etc/firejail/whitelist-run-common.inc
Reading profile /etc/firejail/whitelist-runuser-common.inc
Reading profile /etc/firejail/whitelist-var-common.inc
Seccomp list in: !chroot, check list: @default-keep, prelist: unknown,
Parent pid 12657, child pid 12661
Warning: An abstract unix socket for session D-BUS might still be available. Use --net or remove unix from --protocol set.
Warning: NVIDIA card detected, nogroups command ignored
Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted
Warning: NVIDIA card detected, nogroups command ignored
Seccomp list in: !chroot, check list: @default-keep, prelist: unknown,
Warning: NVIDIA card detected, nogroups command ignored
Warning: NVIDIA card detected, nogroups command ignored
Warning: Replacing profile instead of stacking it. It is a legacy behavior that can result in relaxation of the protection. It is here as a temporary measure to unbreak the software that has been broken by switching to the stacking behavior.
Child process initialized in 141.56 ms
libEGL warning: egl: failed to create dri2 screen
libEGL warning: egl: failed to create dri2 screen
Crash Annotation GraphicsCriticalError: |[0][GFX1-]: Calling WaitFlushedEvent::Run: is delayed: 2115 (t=2.81373) [GFX1-]: Calling WaitFlushedEvent::Run: is delayed: 2115
console.error: ({})
JavaScript error: resource:///modules/SearchSERPTelemetry.sys.mjs, line 1799: TypeError: item is undefined
JavaScript warning: https://www.google.com/js/th/zy9rNhS9wlhNVTKoH2dvsgD5_XMSUSRS4-UwaGEJmsU.js, line 2580: unreachable code after return statement
JavaScript warning: https://www.google.com/js/th/zy9rNhS9wlhNVTKoH2dvsgD5_XMSUSRS4-UwaGEJmsU.js, line 2580: unreachable code after return statement
JavaScript warning: https://www.google.com/js/th/zy9rNhS9wlhNVTKoH2dvsgD5_XMSUSRS4-UwaGEJmsU.js, line 2580: unreachable code after return statement
JavaScript warning: https://www.google.com/js/th/zy9rNhS9wlhNVTKoH2dvsgD5_XMSUSRS4-UwaGEJmsU.js, line 2580: 
...

Пробовал менять профиль добавляя в вайтлист всякие /dev/dri, /dev/nvidia0 - один хрен :(



Последнее исправление: gentoorulz (всего исправлений: 1)
Ответ на: комментарий от gentoorulz

Хотя вот это правило мне очень не нравится:

noblacklist /sys/module

Я пытался его заменить такими:

noblacklist /sys/module/nvidia
noblacklist /sys/module/nvidia_drm
noblacklist /sys/module/nvidia_modeset
noblacklist /sys/module/drm_ttm_helper 
noblacklist /sys/module/drm_kms_helper
noblacklist /sys/module/video
noblacklist /sys/module/drm

Но не помогло, видимо еще что-то нужно лисе

gentoorulz
() автор топика
Ответ на: комментарий от mittorn

nvidia

wayland

Только страдать

Не, ну на вяленном страдать-то однозначно, а нвидия чего. На иксах нормально отрабатывет, уже даже исходники модулей ядра открыли. Нвидия, конечно, особенно в последнее время, охерела, но до покупки GPU от амуде - я до такого пока что «опускаться» не готов. Тем более нейронки, сам понимаешь.

Skullnet ★★★★★
()
Последнее исправление: Skullnet (всего исправлений: 1)
Ответ на: комментарий от mittorn

В таком случае, вейландопроблемы.

На иксах же часто предпочитается glx несмотря на то, что поддерживается и EGL

Да софт на EGL ещё поискать надо.

Skullnet ★★★★★
()
Последнее исправление: Skullnet (всего исправлений: 1)
Ответ на: комментарий от firkax

Нормальный ксорг, где запущенный калькулятор может прочитать буфер браузера? А браузер - keepassxc какой нибудь? Где все приложения читают один общий буфер обмена и могут вносить изменения в работу других окон и контроллить нажатия клавишь? Нет уж, спасибо

gentoorulz
() автор топика
Ответ на: комментарий от mittorn

У тебя давно карточка от нвидии была? Может ты повторяешь слова, которые уже не актуальны? У меня были проблемы с firefox, obsidian и с некоторым другим софтом в вэйланде, но с дровами проблем никаких нет

gentoorulz
() автор топика
Ответ на: комментарий от anonymous

Еще как поможет. Например, взломав лису в Х-сессии смогут прочесть пароли, которые я копирую из keepassxc. В случае с вейландом они ограничатся буферами лисы

gentoorulz
() автор топика
Ответ на: комментарий от gentoorulz

Не ведись на эту чушь, графический сервер далеко не единственный способ что-то украсть. И я уверен, у тебя там ещё десяток каналов разных утечек, про которые ты даже не подозреваешь. Хочешь безопасности - отделяй сомнительное на как минимум отдельных юзеров, а лучше на отдельные компы. А ещё исключи использование таких прог как sudo, pkexec и другое, которое «повышает права»: настроить их безопасно практически невозможно, дефолты - дырявые во всех дистрах, да и сами эти проги пишутся профнепригодными программистами и часто с дырами.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax

Почему чушь? Это не чушь. Но и с тем о чем ты говоришь я согласен. Уровней безопасности должно быть несколько. И по возможности из них следует исключить менее безопасные компоненты, заменив их на более безопасные.

Я не исключаю что Xorg можно настроить более-менее безопасно через какой нибудь SELinux, но это слишком сложно. Архитектура Wayland из коробки выглядит куда более продуманней в плане сесурити

gentoorulz
() автор топика
Ответ на: комментарий от gentoorulz

Нет, SELinux тут ни при чём, и это ещё одна бесполезная штука для псевдобезопасности и создания кучи неудобств либо в работе, либо в виде возни с его настройкой.

Запуск отдельной сесиии (со своим xorg-ом) в том числе для отдельного юзера для запуска сомнительного софта разом решает ряд проблем с доступами куда не надо. И при этом оно не создаёт неудобств от вайландовской псевдобезопасности.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

SELinux тут ни при чём, и это ещё одна бесполезная штука для псевдобезопасности

По-вашему, когда исполняемому файлу позволено лезть куда не следует, вреда для безопасности нет.

и создания кучи неудобств либо в работе

Когда MAC настроен, неудобств в нём нет (помимо пары лишних Ctrl-C Crtl-V). Да, придётся избавиться привычки хранить файлы где попало, но это дурная привычка.

либо в виде возни с его настройкой.

Тут согласен. Настройка SELinux сложна.

Запуск отдельной сесиии (со своим xorg-ом) в том числе для отдельного юзера

Ну т. е. здесь неудобств нет?

И при этом оно не создаёт неудобств от вайландовской псевдобезопасности.

Не хочу раздувать очередной бессмысленный спор Wayland-X11, поэтому просто промолчу.

mister_me
()
Последнее исправление: mister_me (всего исправлений: 1)
Ответ на: комментарий от firkax

Нет, SELinux тут ни при чём, и это ещё одна бесполезная штука для псевдобезопасности и создания кучи неудобств либо в работе, либо в виде возни с его настройкой

Спорное утверждение. Хотя про неудобства с возней согласен, а вот про бесполезность и псевдобезопасность не соглашусь. Но интересно было бы послушать твои аргументы, почему ты так считаешь

Запуск отдельной сесиии (со своим xorg-ом) в том числе для отдельного юзера для запуска сомнительного софта разом решает ряд проблем с доступами куда не надо. И при этом оно не создаёт неудобств от вайландовской псевдобезопасности.

Решает ряд проблем, но не все. Плюс это очень неудобно. Ну и совсем уж сомнительный софт я бы не пускал даже под отдельным юзером, разве что в дополнительной песочнице.

По мне так схема wayland + firejail лучше чем отдельный юзер + xorg, даже не смотря на то что у него suid.

И почему вейланд псевдобезопасен? Он уж точно безопаснее древнющих иксов

gentoorulz
() автор топика
Ответ на: комментарий от mister_me

По-вашему, когда исполняемому файлу позволено лезть куда не следует, вреда для безопасности нет.

Есть конечно, только система прав доступа в юниксах существует уже 50 лет, и эту задачу всегда решала. Надо только настроить её и выкинуть из системы всякие бекдоры типа sudo. Это, конечно, тоже не совсем просто, но проще дроча с selinux-ом.

Ну т. е. здесь неудобств нет?

Я не заметил.

firkax ★★★★★
()
Ответ на: комментарий от gentoorulz

Ну и совсем уж сомнительный софт я бы не пускал даже под отдельным юзером, разве что в дополнительной песочнице.

«Песочница» опирается на всё то же ядро, которое должно куда-то пускать или не пускать. Просто настрой правильно доступы, чтобы юзер не мог лазить по чужим home, tmp итд.

И почему вейланд псевдобезопасен? Он уж точно безопаснее древнющих иксов

Потому что если ты хочешь управлять доступами то графический сервер должен быть запущен от юзера, отдельного от вероятных взломщиков. В противном случае это дверь в чистом поле.

firkax ★★★★★
()
Ответ на: комментарий от firkax

только система прав доступа в юниксах существует уже 50 лет, и эту задачу всегда решала.

Нет. Если программа будет запущена от определённого пользователя, то она может шариться по тем же директориям, что и пользователь.

бекдоры

Бэкдор, тайный вход (от англ. back door — «чёрный ход», «лазейка», буквально «задняя дверь») — дефект алгоритма, который намеренно встраивается в него разработчиком/злоумышленником и позволяет получить несанкционированный доступ к данным или удалённому управлению операционной системой и компьютером в целом.

mister_me
()
Ответ на: комментарий от mister_me

Если программа будет запущена от определённого пользователя, то она может шариться по тем же директориям, что и пользователь.

Да, так и есть (ну, почти, ещё надо группы учитывать). Это и есть система разделения прав. Надо правильно назначать uid:gid всем процессам. И повторю, это лучше чем костыли типа selinux, которые для неосиливших нормальную систему прав.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Свой предыдущий комментарий я случайно опубликовал и не успел отредактировать, продолжу мысль в этом.

sudo

На серверах (т. е. там, где больше всего нужна безопасность) нормальной замены нет (или я не разобрался, как в opendoas логгирование ведётся).

проще дроча с selinux-ом.

Есть apparmor, который проще. На крайний случай firejail (тоже позволяет не пускать).

Я не заметил.

На мой же взгляд, работать на двух пользователях менее удобно, чем таскать файлики куда надо.

mister_me
()
Ответ на: комментарий от firkax

Надо правильно назначать uid:gid всем процессам. И повторю, это лучше чем костыли типа selinux

Чем же DAC в этом плане лучше MAC? В первом нужно назначать uid:gid процессам и владельцев файлам, во втором нужно назначать доступные файлы.

костыли типа selinux, которые для неосиливших нормальную систему прав.

Надо полагать, в АНБ сплошь засели неосиляторы.

mister_me
()
Ответ на: комментарий от firkax

«Песочница» опирается на всё то же ядро, которое должно куда-то пускать или не пускать. Просто настрой правильно доступы, чтобы юзер не мог лазить по чужим home, tmp итд.

Погугли PEASS, запусти под своим «изолированным» юзером и офигей от того сколько прелестей будет открыто и закрыть их ты никак не сможешь правами доступа к ФС

это лучше чем костыли типа selinux, которые для неосиливших нормальную систему прав.

По-моему ты сравниваешь холодное с мокрым. И осилить selinux, не осилив при этом права доступа ФС - с трудом себе представляю такое явление

gentoorulz
() автор топика
Ответ на: комментарий от mister_me

На серверах (т. е. там, где больше всего нужна безопасность) нормальной замены нет (или я не разобрался, как в opendoas логгирование ведётся).

Замены чему? Он по своему принципу не нужен. Сама идея «повышения прав» неисправимо дефективна, её не надо ни в виде sudo ни в виде других реализаций использовать. У системного администратора есть пароль к руту и группа wheel - для этого su. Логин через юзера тут только для всеобщего удобства и немного усложнения жизни взломщикам (хотя если авторизация по паролю отключена то второе наверно не меняется).

Есть apparmor, который проще. На крайний случай firejail (тоже позволяет не пускать).

Опять: системы списков доступа на основе имён файлов и имён программ не нужны, ни в виде selinux, ни в виде его аналогов. Нужна настройка доступа в виде uid:gid процесса и uid:gid+mode файловых инод.

На мой же взгляд, работать на двух пользователях менее удобно, чем таскать файлики куда надо.

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

Не бывает полностью бесшовной и при этом безопасной работы опасного софта, а везде где тебе такое предлагают: знай, они врут и там где-то дыра.

firkax ★★★★★
()
Ответ на: комментарий от mister_me

Чем же DAC в этом плане лучше MAC? В первом нужно назначать uid:gid процессам и владельцев файлам, во втором нужно назначать доступные файлы.

Тем что первый оперирует объектами, а второй - текстовыми строками, на них ссылающимися, это плохой подход и к sudo кстати та же претензия - списки разрешённых действий в нём настраиваются регулярками на командную строку.

Надо полагать, в АНБ сплошь засели неосиляторы.

Скорее там что-то связанное с не-ИТ традициями систем доступа всяких служб.

firkax ★★★★★
()
Ответ на: комментарий от gentoorulz

Погугли PEASS, запусти под своим «изолированным» юзером и офигей от того сколько прелестей будет открыто и закрыть их ты никак не сможешь правами доступа к ФС

Мог бы просто сказать «в линуксе регулярно находят дыры», нет надо на какой-то эксплойт-пак сослаться. Так вот, ты возможно не в курсе, но privilege escalation, в зависимости от того где именно оно обнаружилось, может обойти как доступы по uid, так и твои песочницы. В этом плане да, песочница некоторый смысл имеет: надев друг на друга два решета (права к файлам и песочницу), надеемся что их дырки нигде не окажутся рядом. Но ты, кажется, уверен что оно тебя защитит, зря это. Рекомендую заменить линукс на фрибсд или опенбсд для начала, в них дыр меньше.

firkax ★★★★★
()
Ответ на: комментарий от firkax

privilege escalation, в зависимости от того где именно оно обнаружилось, может обойти как доступы по uid, так и твои песочницы

Я в курсе, именно потому и топлю за многослойные уровни защиты

Но ты, кажется, уверен что оно тебя защитит, зря это

Нет, это твои домыслы, я нигде про это не говорил

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

Дыр в них плюс-минус столько же, просто они менее популярны. Но с самой рекомендацией согласен. В идеале вообще везде где можно использовать разные ОС и дистрибутивы. Например, на хосте Linux Slackware, в виртуалке, которая будет gateway - gentoo (openrc), в виртуалке workstation - openbsd. Ну и тд

gentoorulz
() автор топика
Ответ на: комментарий от firkax

это плохой подход

С точки зрения безопасности разницы нет, потому что эти строки всё равно только от рута редактируются, а если малварь получила рут, то уже нет разницы, какая защита установлена. А ещё конфигурационный файл можно легко перенести на новую систему.

mister_me
()
Ответ на: комментарий от firkax

Он по своему принципу не нужен

A few moments later...

Логин через юзера тут только для всеобщего удобства и немного усложнения жизни взломщикам

Сама идея «повышения прав» неисправимо дефективна

Только если пускать козла в огород доверять криворукому пользователю.

Таскание файликов между надёжным и ненадёжным юзером следует свести к минимуму

Что же делать, если есть необходимость?

Необходимость каких-то явных действий для этого таскания вполне помогает этого достичь - ты по крайней мере не сделаешь это случайно.

Как вообще можно случайно сделать cp /home/user1/file /home/user2/file?

Не бывает полностью бесшовной и при этом безопасной работы опасного софта

Ну это аксиома.

mister_me
()
Ответ на: комментарий от xDShot

Я пытался недавно его потестировать и пришёл к следующему выводу: либо я криворукий, либо разработчики wayland исправили дыру за те пять лет, что проект не обновлялся.

mister_me
()
Ответ на: комментарий от mister_me

Разница в том, что связи между объектами всегда остаются на месте, и за их консистентностью следит код, их поддерживающий, «в реальном времени» и бесплатно. Когда же у тебя права прописаны в виде таблиц разных текстовых строк, следить за этим всем приходится тебе самому вручную. Переместил какой-то файл (прогу ли или тот, к кому надо доступ ограничить) - и всё, таблица уже указывает мимо. Создал - а про него нет записи. В лучшем случае какой-нить проверяльщик конфигов тебя оповестит о странной ситуации чтобы ты начал её исправлять. Это всё бредовая работа, лишняя трата времени и чревато ошибками. В случае объектов всё что надо указано в самом объекте сразу, а так же нативно интегрировано со всеми имеющимися механизмами ОС, а не выглядит приделанными сбоку костылями.

firkax ★★★★★
()
Ответ на: комментарий от mister_me

A few moments later...

Не понял претензии. Админский логин через юзера - это не «повышение прав». Админ изначально считается имеющим рут-права, ничего кроме su ему из под логин-юзера вводить не надо. То есть: залогинился за юзера (ключ или пароль), ввёл su -, ввёл рут пароль, работаешь. Если надо сделать что-то с пониженными правами - делаешь su в юзера с пониженными правами (это не тот юзер, которым ты логинился, а другой, без возможности в него напрямую залогиниться вообще, и для разных задач разный, где-то возможно одноразовый) для этой задачи (хотя я, на freebsd, обычно использую jail/jexec для таких дел, и опционально уже внутри него su, ещё полезно делать это в screen-е чтобы недоверенный юзер не испортил настройки рутового tty).

Как вообще можно случайно сделать cp /home/user1/file /home/user2/file?

Вот именно что никак. А когда у тебя всё от одного юзера и вместо нормального разделения прав какие-то костыли - вполне можно.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)