Wayland Compositors - Why and How to Handle Privileged Clients!

X-мены, осилившие текст, что скажете?

пусть пилят, убунту перейдет сразу на вайленд сразу как дебиан перейдет

Не прошло и полувека.

Ждём integrity levels.

Одни пеар набросы в течении 5 лет и по факту ни одного дистрибутива перешедшего на эту хрень.

X-мены

XXX-мены :) петросян.жепег

Вроде какие то фирмы решали этот вопрос по заказу ВС РФ. Правда их наработки так и не были опубликованы.

А если не коротко. То как он намерен это реализовать?

Заодно спросим начальника транспортного цеха no-dashi

А если не коротко. То как он намерен это реализовать?

1. там МНОГО букв.

2. например

A default policy could be specified in /etc/wayland/security.conf. Per-client configuration could be stored in /etc/wayland/authorized_clients.d/. This would allow package managers to install application security policies along with the application. Each application-specific policy would define the full path of the allowed binary and which restricted interface the application needs to get access to and in which cases is it acceptable (only when run by the compositor? etc…). This is enables Trusted Path Execution (TPE) as only the binary specified by the fullpath will match this set of privileges.

Different UNIX users should be allowed to have different security parameters. The easiest way would be to store per-user configuration in different files in /etc/wayland/users.d/ in order to simplify the logic. Another possibility would be to have ~/.wayland/ overriding the /etc/wayland/ configuration folder. The latter solution would be harder to implement securely because only the compositor should be allowed to change the configuration.

In any case, to be considered valid, configuration files should all be root-owned and 644 to prevent malicious applications from changing the security policy. This means changing the security policy will be considered as an administrative task which sounds about right.

Чего ты хотел услышать? Что в вяленде можно прикинуться композитором и внутри себя запустить клиента и так же эффективно - и даже еще более эффективно - воровать скриншоты окна и клавиатурный ввод? Или что в качестве «засчиты» вялендун предложил анально огородить вяленд?

Что в вяленде можно прикинуться композитором и внутри себя запустить клиента и так же эффективно - и даже еще более эффективно - воровать скриншоты окна и клавиатурный ввод?

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

Или что в качестве «засчиты» вялендун предложил анально огородить вяленд?

поясни

Мат часть учи. Не любое, а то, которому позволили. Тебя xhost + заставляли делать с пистолетом?

Fix­ing the other se­cu­rity prop­er­ties is im­pos­si­ble us­ing the X11 pro­to­col as it would break too many le­git­i­mate ap­pli­ca­tions that rely on those fea­tures

Усиление security ломает программы, реально ломающие новости.

А слушать весь ввод позволено всем приложениям, запущенным на данных иксах локально безо всякого xhost +.

Не любое, а то, которому позволили.

что, блджад, значит позволили? как мне запустить 2 приложения на _одних_ иксах, чтобы они не получали события ввода, когда фокус находится в другом приложении?

как мне запустить 2 приложения на _одних_ иксах, чтобы они не получали события ввода, когда фокус находится в другом приложении?

Ты из мастурбирущих на безопасность обезьян? Если нет, то просто не запускай всякую х..ню, и тебя не будет волновать такой вопрос.

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

А слушать весь ввод позволено всем приложениям, запущенным на данных иксах локально безо всякого xhost +.

А запускаться «на данных иксах» - даже «локально» позволено не мифическим «всем», а только тем, кому ты разрешил видеть доступ к .Xauthority - поэтому если его у тебя имеют «все», то ты ССЗБ. Ты бы ещё chmod -R 777 ~ сделать, а потом кричал что «сраный линупс позволяет всем смотреть, править и удалять мои файлы».

И в этот момент у злонамеренного приложения в нормальной системе не хватает прав на общение с другими приложениями вообще.

Ты из мастурбирущих на безопасность обезьян?

Если на безопасность не мастурбировать, случается такое.

как мне запустить 2 приложения на _одних_ иксах, чтобы они не получали события ввода, когда фокус находится в другом приложении?

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

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

Для кейлоггеров.

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

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

Для кейлоггеров.

То есть реализация нормальной security в X сломает кейлоггеры, какая потеря. Что еще сломается?

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

Прекрати. Даже удалённое приложение имеет абсолютно полные права в пределах иксов. При этом оно не может убивать процесс (хотя может попытаться обрушить), но может слушать ввод в том числе привилегированных окон и слать туда любые события. Это — решето.

в том числе привилегированных окон

Упс. В иксах их нет. Как и вообще разделения привилегий.

И в этот момент у злонамеренного приложения в нормальной системе не хватает прав на общение с другими приложениями вообще.

Если ты запустил локальную какую-то муйню под своей учеткой, то твой браузер она прибьет и запустит за милую душу. Добро пожаловать в реальный мир.

Если на безопасность не мастурбировать, случается [...winlocker...]

Нет, если на безопасность мастурбировать, то случается удаление переднего резца через нос. А если нет, то можно запускать недоверенные приложения в rootless nested x-сервер.

Даже удалённое приложение имеет абсолютно полные права в пределах иксов.

А нафейхоа ты запускаешь в основном X-сервере недоверенное удаленное приложение?

Ты из мастурбирущих на безопасность обезьян

ой как предметно, продолжай

просто не запускай всякую х..ню, и тебя не будет волновать такой вопрос.

ты не считаешь, например, скайп х..ней? или ты предлагаешь не запускать скайп?

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

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

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

для xneur, krunner, всякие там xev

То есть реализация нормальной security в X сломает кейлоггеры, какая потеря. Что еще сломается?

реализация нормальной security в X была бы вином, несмотря на сломавшиеся кейлоггеры, а она уже есть?

Если ты запустил локальную какую-то муйню под своей учеткой, то твой браузер она прибьет и запустит за милую душу.

по ссылке не ходил, так и скажи.

Input integrity means that no application can pretend to be the user and send forged input to another application. If this were allowed, applications could perform confused deputy-like privilege escalations. Integrity doesn’t only mean that the input hasn’t been tampered with, it also means that the source of the data really is the one advertised. Without integrity, if an application was not allowed to directly access a file but the user could, the application would only have to fake sending the “Alt + F2” key sequence and key-in the commands it wants to execute. This isn’t problematic in poorly-secured Operating Systems but becomes a problem when applications start running with less privileges than the user who started them.

The first good point of the Wayland protocol is input management. At the moment, the protocol doesn’t allow snooping on the input (confidentiality), generating input events (integrity) nor for an application to grab all events (availability). However, Wayland clients allowing LD_PRELOAD are still vulnerable to input attacks, as demonstrated by Maarten Baert. This is not Wayland compositors’ problem so it won’t be taken into account in this discussion.

если ты даже столько текста не осилишь - в иксах это возможно, в вяленом - нет.

реализация нормальной security в X была бы вином, несмотря на сломавшиеся кейлоггеры, а она уже есть?

Насколько я понял аффтара, ее не пишут, чтобы не сломать кейлоггеры %)

если ты даже столько текста не осилишь - в иксах это возможно, в вяленом - нет.

Насколько я понял, но-дачи говорит о той самой «Wayland compositors’ problem», которая " won’t be taken into account in this discussion".

а эта проблема на самом деле рассматривается, конкретно в этой статье очень вскользь (ибо речь о другом)

Launch­ing priv­i­leged Way­land clients from the com­pos­i­tor

The most-se­cure way of launch­ing clients re­quir­ing re­stricted in­ter­faces is to let the com­pos­i­tor run them by it­self. This way, it can con­trol the en­vi­ron­ment in which the process has been launched which low­ers the risks of en­vi­ron­ment at­tacks such as the LD_PRELOAD one ex­posed ear­lier.

Im­ple­ment­ing such a sys­tem is dif­fi­cult as the com­pos­i­tor needs to re­mem­ber that the PID of the client it launched should be granted the priv­i­leges to ac­cess one or more re­stricted in­ter­faces when this (soon-to-be­come)client con­nects to the Way­land com­pos­i­tor. Not only does it mean that the com­pos­i­tor needs to have a sep­a­rate table of which PIDs are sup­posed to get which priv­i­leges, it also means the com­pos­i­tor needs to keep track of the death of the client’s PID to avoid an­other process from re-us­ing the PID of this client and gain­ing ac­cess to priv­i­leged in­ter­faces it wasn’t sup­posed to ac­cess.

A sim­pler and more se­cure so­lu­tion would be for the com­pos­i­tor to open a UNIX socket to it­self be­fore exec’ing the client. Once opened, it should be sim­pler for the com­pos­i­tor to set the client’s ca­pa­bil­i­ties to a flag stored in the struc­ture track­ing the client and then ex­e­cute the client’s bi­nary. When run­ning the exec() syscall, all the FDs that have not been opened with the O_CLOEXEC flag will be passed on to the new process. A run-time pa­ra­me­ter of the Way­land client could then be used to tell which FD rep­re­sents the unix socket to the Way­land com­pos­i­tor. An ex­am­ple of such pa­ra­me­ter could be --wayland-fd=xxx. The com­pos­i­tor should how­ever be care­ful it doesn’t leak any un-needed FD to the new client.

2014/02/21 UP­DATE: Pekka Paala­nen said on the Way­land Mail­ing List the lat­ter ap­proach is al­ready im­ple­mented in Way­land and sug­gested read­ing the doc­u­men­ta­tion about the en­vi­ron­ment vari­able WAYLAND_SOCKET in wl_dis­play_­con­nect. I ac­tu­ally pre­fer the im­ple­mented so­lu­tion bet­ter be­cause it is trans­par­ent to ap­pli­ca­tions. Well done!

Это что, сценарий confused deputy privilege escalation? %)

Не слушал, но мне больше Чайковский нравится. А подобные темы мне не нравятся, слащаваые они какие-то... одно слово - румыны.

Любое приложение — недоверенное. И неплохо было бы уменьшить вред от его потенциальной уязвимости, чем занимаются в том числе SELinux/AppArmor/TOMOYO Linux. В конце концов, даже оффтопик 7 лет как умеет это. А в иксах любой nobody@левый-хост имеет ровно те же права, что root@localhost.

Любое приложение — недоверенное

this

ну на сколько я понял - да, но могу ошибаться