LINUX.ORG.RU

Security by isolation

 


0

3

В Qubes заложена концепция $subj - то есть, например, эксплоит браузера точно не украдёт ваши ssh-ключики, если, конечно, браузер работает в той виртуалке, в которой ваши ключики не хранятся.

До внятного знакомства с Qubes сам стал думать на тему изоляции важных данных от недоверенных программ, и думал в сторону того, чтобы ключи хранились у одного пользователя в $HOME, а браузер запускался под другим. Но такая схема вносит сложности в работу и выглядит велосипедно.

А какими мерами вы пользуетесь для $subj? Прокомментируйте, пожалуйста, архитектуру Qubes и мою велосипедостроительную идею.

Я работал с подобной внутренней системой изоляций.

Это интересно и заманчиво, но только на этапе начала использования такого подхода.

Потом, при определённых кейсах, ты хочешь, скажем дать приложению A доступ к функционалу/пространству приложения B, что бы они могли содействовать. Через полгода, условно, у тебя уже сотня-другая пересекающихся исключений и допусков. А потом, еще через полгода, ты понимаешь что в этой паутине уже не так то и весело, и задумываешься над тем что тратишь больше времени на обслуживание этих допусков, чем на работу с приложениями.

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

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

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

oblepiha_pie
()

Но такая схема вносит сложности в работу

Совершенно никаких сложностей. Именно так и работаю. Я, браузер, криптокошельки и Viber работаем под разными пользователями.

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

Спасибо за коммент, значит, я не один имею такое отношение к вещам.

Krieger_Od ★★
() автор топика

безопасность, базирующаяся на если, это как правило «если-безопасность»

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

Можете подсказать, вы делаете какую-либо защиту от случайного/нечаянного запуска недоверенных приложений, например, браузеров, в окружении, для этого не предназначенном? То есть, реализуете ли whitelist допустимых приложений? Подскажите, пожалуйста, как это удобнее реализовать. Ну и вообще советами/конфигами поделитесь, если есть, чем.

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

Нет, в данном случае это не требуется; цель - изоляция данных. Только что потыкал на ссылки в Bitcoin-кошельке - там браузер просто не запускается. Даже если бы запустилось - оно не имеет доступа к данным основного браузера, так что такое допустимо.

Подскажите, пожалуйста, как это удобнее реализовать.

Сходу на ум разве что группы приходят. Меняем права на бинарники, убираем права запуска «всем», создаем новую группу и ставим ее бинарнику, Нужным пользователям добавляем ту же группу. Реализуется быстро, легко, не требует стороннего софта. Но не спасает от возможности запустить собственную копию приложения. В целом, все зависит от задач. Так можно и до написания правил grsec для каждого приложения дойти :)

Ну и вообще советами/конфигами поделитесь, если есть, чем.

А там особо и нечем - конфигурация-то крайне простая. Для кошельков просто созданы кнопки, где через sudo запускается процесс под другим пользователем. Для браузера - враппер примерно с тем же контентом, но который указывается в приложениях в качестве браузера и размещенный в ~/bin пользователя. Во враппере разве что добавлен umask, чтобы мой пользователь, находящийся в группе браузера, мог работать со скачанными файлами (на каталоге загрузки SGID-бит и группа моего пользователя, так что мой пользователь может свободно делать все, что угодно с файлами), плюс сорсится vdpau-va-gl для включения ускорения. Ну и группа audio для пользователя firefox для того, чтобы звук в видеороликах работал. В общем-то и все.

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

Мне тут подсказал товарищ Harald, что SELinux спасает секретные ключики и прочую sensitive data отцов русской демократии. Попробую в ближайшее время освоить такую изоляцию, вместо мультиюзерства - я начал её внедрять, но полезли бока: например, чтобы позволить псевдоюзеру запустить оконное приложение в Xorg-сессии, надо выполнить «xhost +» для разрешения на это.

Andrey_Utkin ★★
()
20 марта 2016 г.
Ответ на: комментарий от Andrey_Utkin

qubes-то про черные шапки, а не про белые- когда вам какойнить сплоит или фирмварь с флешки ядро проломит, эти ваши чмоды будут выглядеть несерьёзно http://blog.invisiblethings.org/papers/

hotbot
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.