форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"Новый механизм для безопасного выполнения подозрительных про..."		+/–
Сообщение от opennews (ok) on 27-Май-09, 19:22
Dan Walsh и Eric Paris, участвующие в разработке SELinux, представили (http://lkml.org/lkml/2009/5/26/269) новый механизм для безопасного выполнения  не испытывающих доверия приложений в Linux. Утилита sandbox позволяет (http://danwalsh.livejournal.com/28545.html) выполнить программу с максимальным уровнем изоляции SELinux, при котором запрещен доступ к сетевым функциям и работе с файлами. Для определения базовых полномочий, доступных выполняемому приложению, используется SELinux политика sandbox_t, которую можно изменить в зависимости от текущей ситуации через стандартный GUI-интерфейс system-config-selinux. Утилита sandbox уже включена в состав пакетов selinux-policy-3.6.12-41.fc11 и policycoreutils-2.0.62-12.6.fc11, подготовленных для дистрибутива Fedora 11. В будущем планируется реализовать набор дополнительных политик, позволяющих приложению работать с заданным набором файлов в специально отведенной временной директории. Также будет добавлена опция "--mount",  дающая возможность монитрования tmpfs раздела в качестве рабочей директории на лету. URL: http://lkml.org/lkml/2009/5/26/269 Новость: http://www.opennet.me/opennews/art.shtml?num=21913
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Новый механизм для безопасного выполнения подозрительных про..."		+2 +/–
Сообщение от Анонимус (ok) on 27-Май-09, 19:22
великолепно! Ещё бы сделали чтоб можно было без особых манипуляций запустить программку в песочнице - например, если мне она нужна только один раз, то прописывать политики как-то лень.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Новый механизм для безопасного выполнения подозрительных про..."		–1 +/–
Сообщение от pavlinux (ok) on 28-Май-09, 01:22
> # sandbox cut -d: -f1 /etc/passwd > /tmp/users > /bin/cut: /etc/passwd: Permission denied > Which shows the sandbox domain is not allowed > to open /etc/passwd > But I can execute > # cat /etc/passwd | sandbox cut -d: -f1 > /tmp/users 1. Утверждение: В sandbox запрещен доступ к работе с файлами! 2. В примере cut разрешилось записать в файл - STDOUT !!! 3. Работа с STDIN/STDOUT в экваквалентна  работе с файлами. 4. В Unix - всё файлы, за исключением железа и напряжения в проводниках :) Как видим 2, 3 и 4 - ФАКТЫ, а 1 мечта афтора! Почти исключение - зомби, - ни хрена не делают, хотя числятся в списке процессов, как половина сотрудников НИИ или наша группа в институте :)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Новый механизм для безопасного выполнения подозрительных про..."		+/–
	Сообщение от szh (ok) on 28-Май-09, 01:39
	с переданными запускающим файловами дескрипторами процесс работать может, а других файлов открыть не может
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Новый механизм для безопасного выполнения подозрительных про..."		+/–
	Сообщение от pavlinux (ok) on 28-Май-09, 01:40
	>с переданными запускающим файловами дескрипторами процесс работать может, а других файлов открыть >не может Чем open(/etc/passwd) хуже open(STDIN)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Новый механизм для безопасного выполнения подозрительных про..."		+1 +/–
	Сообщение от pavlinux (ok) on 28-Май-09, 01:56
	А я придумал ..... Надо ещё написать утилитку fd - (file descriptor), которая открывает файл, а файловый дескриптор передаёт в sandbox и всё время работать в паре # fd -i /etc/passwd | sandbox grep root | fd -o stdout :) ещё можно добавить Blowfish шифровалку и SHA512 хэшу. Причем, sandbox должен сгенерить открытый ключ, а fb подписывать переданный файловый дескриптор этим ключом, который находиться, только на сервере ключей, не локально. Тоже самое делает sandbox на выходе, только подписывает открытым ключом от fd. Тогда наша команда превращается, в следующую: # fd -i /etc/passwd  -s https://keyserver.secretdomain.com/users/vasya/sanbox-290520... -e blowfish -x sha512 |  sandbox -k 0x12DC43F65A3 -o fd-29052009 -ix sha512 -c  grep root |  fd -o stdout -s https://keyserver.secretdomain.com/server/private/fd-2905200... -dx sha512   Естественно, сертификат на SSL соединение выдаётся на сервере. Добавить харварный генератор случайных байтоф, сертифицированный ФСБ. И ещё добавить PAX от grSecurity - и убится апстену....... (to be continued...)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Новый механизм для безопасного выполнения подозрительных про..."		+/–
	Сообщение от triz0r on 28-Май-09, 13:10
	>[оверквотинг удален] > ># fd -i /etc/passwd  -s https://keyserver.secretdomain.com/users/vasya/sanbox-290520... -e blowfish -x sha512 | > sandbox -k 0x12DC43F65A3 -o fd-29052009 -ix sha512 -c  grep >root |  fd -o stdout -s https://keyserver.secretdomain.com/server/private/fd-2905200... -dx sha512 > >Естественно, сертификат на SSL соединение выдаётся на сервере. >Добавить харварный генератор случайных байтоф, сертифицированный ФСБ. >И ещё добавить PAX от grSecurity - и убится апстену....... > >(to be continued...) Ага, а для связи с keyserver  -использовать шифрованный канал - для получения ключа SSL, аутентификация через PKI, шифрование сессии - только симметричным ключом размером 4096. хеш ключа генерируется с привязкой к железу ... Т.е. до запуска команды # fd -i ...надо ещё парочку налабать :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Новый механизм для безопасного выполнения подозрительных про..."		+/–
	Сообщение от User294 (ok) on 28-Май-09, 13:43
	>И ещё добавить PAX от grSecurity - и убится апстену....... >(to be continued...) Это как?! Necromancy is a forbidden art (c) :P
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "тем, что open(STDIN) не выполняется приложением"		+/–
	Сообщение от Вова on 28-Май-09, 16:38
	для работы с файлом /etc/passwd необходим системный вызов open(/etc/passwd), для работы с stdin - нет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "тем, что open(STDIN) не выполняется приложением"		+/–
	Сообщение от pavlinux (ok) on 28-Май-09, 20:09
	т.е. предлагаешь через getc/putc работать ....
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "Новый механизм для безопасного выполнения подозрительных про..."		+/–
Сообщение от Thorn (??) on 29-Май-09, 11:42
Наконец-то начали латать этот Решетинукс! Только поздно уже... По идее, ЛЮБАЯ программа не должна вылезать за пределы своей директории, а всякие запросы к /dev/* осуществлять через системные сервисы (где и проверяются все пермишыны).
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "Новый механизм для безопасного выполнения подозрительных про..."		+/–
	Сообщение от HoverHell (ok) on 29-Май-09, 13:07
	>Наконец-то начали латать этот Решетинукс! Только поздно уже... > >По идее, ЛЮБАЯ программа не должна вылезать за пределы своей директории, а >всякие запросы к /dev/* осуществлять через системные сервисы (где и проверяются >все пермишыны). open('/dev/smth') тот же системный запрос позволяющий ту же регулировку прав :) А вот open('/home/some1/.gnupg/secring.gpg') уже не выглядит так хорошо (если это делает не '/usr/bin/gpg'). Как и exec самого /usr/bin/gpg, хотя. То есть говоря, для большей безопасности у одного пользователя должна быть (хотя бы!) возможность определять, к чему есть доступ определённых программ. Вроде того, как это делается для системных демонов. (Только вот firefox у меня использует очень много всего включая gpg, и при этом, наверное, является наибольшей потенциальной дырой в системе…)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]