URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 55024
[ Назад ]

Исходное сообщение
"Новый механизм для безопасного выполнения подозрительных про..."

Отправлено opennews , 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


Содержание

Сообщения в этом обсуждении
"Новый механизм для безопасного выполнения подозрительных про..."
Отправлено Анонимус , 27-Май-09 19:22 
великолепно! Ещё бы сделали чтоб можно было без особых манипуляций запустить программку в песочнице - например, если мне она нужна только один раз, то прописывать политики как-то лень.

"Новый механизм для безопасного выполнения подозрительных про..."
Отправлено pavlinux , 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 мечта афтора!


Почти исключение - зомби, - ни хрена не делают, хотя числятся в списке процессов, как половина сотрудников НИИ или наша группа в институте :)
  


"Новый механизм для безопасного выполнения подозрительных про..."
Отправлено szh , 28-Май-09 01:39 
с переданными запускающим файловами дескрипторами процесс работать может, а других файлов открыть не может

"Новый механизм для безопасного выполнения подозрительных про..."
Отправлено pavlinux , 28-Май-09 01:40 
>с переданными запускающим файловами дескрипторами процесс работать может, а других файлов открыть
>не может

Чем open(/etc/passwd) хуже open(STDIN)


"Новый механизм для безопасного выполнения подозрительных про..."
Отправлено pavlinux , 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...)  


"Новый механизм для безопасного выполнения подозрительных про..."
Отправлено triz0r , 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 ...надо ещё парочку налабать :)


"Новый механизм для безопасного выполнения подозрительных про..."
Отправлено User294 , 28-Май-09 13:43 
>И ещё добавить PAX от grSecurity - и убится апстену.......
>(to be continued...)

Это как?! Necromancy is a forbidden art (c) :P


"тем, что open(STDIN) не выполняется приложением"
Отправлено Вова , 28-Май-09 16:38 
для работы с файлом /etc/passwd необходим системный вызов open(/etc/passwd), для работы с stdin - нет.

"тем, что open(STDIN) не выполняется приложением"
Отправлено pavlinux , 28-Май-09 20:09 
т.е. предлагаешь через getc/putc работать ....



"Новый механизм для безопасного выполнения подозрительных про..."
Отправлено Thorn , 29-Май-09 11:42 
Наконец-то начали латать этот Решетинукс! Только поздно уже...

По идее, ЛЮБАЯ программа не должна вылезать за пределы своей директории, а всякие запросы к /dev/* осуществлять через системные сервисы (где и проверяются все пермишыны).


"Новый механизм для безопасного выполнения подозрительных про..."
Отправлено HoverHell , 29-Май-09 13:07 
>Наконец-то начали латать этот Решетинукс! Только поздно уже...
>
>По идее, ЛЮБАЯ программа не должна вылезать за пределы своей директории, а
>всякие запросы к /dev/* осуществлять через системные сервисы (где и проверяются
>все пермишыны).

open('/dev/smth') тот же системный запрос позволяющий ту же регулировку прав :)
А вот open('/home/some1/.gnupg/secring.gpg') уже не выглядит так хорошо (если это делает не '/usr/bin/gpg'). Как и exec самого /usr/bin/gpg, хотя.

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

(Только вот firefox у меня использует очень много всего включая gpg, и при этом, наверное, является наибольшей потенциальной дырой в системе…)