https://www.opennet.ru/openforum/vsluhforumID3/55024.html Dan Walsh и Eric Paris, участвующие в разработке SELinux, представили (http://lkml.org/lkml/2009/5/26/269) новый механизм для безопасного выполнения не испытывающих доверия приложений в Linux. Утилита sandbox позволяет (http://danwalsh.livejournal.com/28545.html) выполнить программу с максимальным уровнем изоляции SELinux, при котором запрещен доступ к сетевым функциям и работе с файлами. <br><br><br>Для определения базовых полномочий, доступных выполняемому приложению, используется SELinux политика sandbox_t, которую можно изменить в зависимости от текущей ситуации через стандартный GUI-интерфейс system-config-selinux. Утилита sandbox уже включена в состав пакетов selinux-policy-3.6.12-41.fc11 и policycoreutils-2.0.62-12.6.fc11, подготовленных для дистрибутива Fedora 11.<br><br><br>В будущем планируется реализовать набор дополнительных политик, позволяющих приложению работать с заданным набором файлов в специально отведенной временной директории. Также будет добавлена опция "--mount", дающая возможность монитрования tmp https://www.opennet.ru/openforum/vsluhforumID3/55024.html#23 Fri, 29 May 2009 09:07:08 GMT &gt;Наконец-то начали латать этот Решетинукс! Только поздно уже... <br>&gt;<br>&gt;По идее, ЛЮБАЯ программа не должна вылезать за пределы своей директории, а <br>&gt;всякие запросы к /dev/* осуществлять через системные сервисы (где и проверяются <br>&gt;все пермишыны). <br><br>open('/dev/smth') тот же системный запрос позволяющий ту же регулировку прав :)<br>А вот open('/home/some1/.gnupg/secring.gpg') уже не выглядит так хорошо (если это делает не '/usr/bin/gpg'). Как и exec самого /usr/bin/gpg, хотя.<br><br>То есть говоря, для большей безопасности у одного пользователя должна быть (хотя бы!) возможность определять, к чему есть доступ определённых программ. Вроде того, как это делается для системных демонов.<br><br>(Только вот firefox у меня использует очень много всего включая gpg, и при этом, наверное, является наибольшей потенциальной дырой в системе&#8230;)<br> https://www.opennet.ru/openforum/vsluhforumID3/55024.html#22 Fri, 29 May 2009 07:42:12 GMT Наконец-то начали латать этот Решетинукс! Только поздно уже...<br><br>По идее, ЛЮБАЯ программа не должна вылезать за пределы своей директории, а всякие запросы к /dev/* осуществлять через системные сервисы (где и проверяются все пермишыны).<br> https://www.opennet.ru/openforum/vsluhforumID3/55024.html#21 Thu, 28 May 2009 16:09:22 GMT т.е. предлагаешь через getc/putc работать .... <br><br><br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/55024.html#20 Thu, 28 May 2009 12:38:44 GMT для работы с файлом /etc/passwd необходим системный вызов open(/etc/passwd), для работы с stdin - нет. <br> https://www.opennet.ru/openforum/vsluhforumID3/55024.html#19 Thu, 28 May 2009 09:43:58 GMT &gt;И ещё добавить PAX от grSecurity - и убится апстену....... <br>&gt;(to be continued...) <br><br>Это как?! Necromancy is a forbidden art (c) :P<br> https://www.opennet.ru/openforum/vsluhforumID3/55024.html#18 Thu, 28 May 2009 09:10:54 GMT &gt;[оверквотинг удален]<br>&gt;<br>&gt;# fd -i /etc/passwd -s https://keyserver.secretdomain.com/users/vasya/sanbox-29052009.rsa -e blowfish -x sha512 &#124; <br>&gt; sandbox -k 0x12DC43F65A3 -o fd-29052009 -ix sha512 -c grep <br>&gt;root &#124; fd -o stdout -s https://keyserver.secretdomain.com/server/private/fd-29052009.rsa -dx sha512 <br>&gt;<br>&gt;Естественно, сертификат на SSL соединение выдаётся на сервере. <br>&gt;Добавить харварный генератор случайных байтоф, сертифицированный ФСБ. <br>&gt;И ещё добавить PAX от grSecurity - и убится апстену....... <br>&gt;<br>&gt;(to be continued...) <br><br>Ага, а для связи с keyserver -использовать шифрованный канал - для получения ключа SSL, аутентификация через PKI, шифрование сессии - только симметричным ключом размером 4096. хеш ключа генерируется с привязкой к железу ... <br>Т.е. до запуска команды<br># fd -i ...надо ещё парочку налабать :)<br> https://www.opennet.ru/openforum/vsluhforumID3/55024.html#13 Wed, 27 May 2009 21:56:56 GMT А я придумал .....<br><br>Надо ещё написать утилитку fd - (file descriptor),<br>которая открывает файл, а файловый дескриптор передаёт в sandbox <br>и всё время работать в паре <br><br># fd -i /etc/passwd &#124; sandbox grep root &#124; fd -o stdout <br><br>:)<br><br>ещё можно добавить Blowfish шифровалку и SHA512 хэшу. <br>Причем, sandbox должен сгенерить открытый ключ, а fb <br>подписывать переданный файловый дескриптор этим ключом, <br>который находиться, только на сервере ключей, не локально. <br>Тоже самое делает sandbox на выходе, только подписывает <br>открытым ключом от fd. <br><br>Тогда наша команда превращается, в следующую: <br><br><br># fd -i /etc/passwd -s https://keyserver.secretdomain.com/users/vasya/sanbox-29052009.rsa -e blowfish -x sha512 &#124; sandbox -k 0x12DC43F65A3 -o fd-29052009 -ix sha512 -c grep root &#124; fd -o stdout -s https://keyserver.secretdomain.com/server/private/fd-29052009.rsa -dx sha512 <br><br>Естественно, сертификат на SSL соединение выдаётся на сервере. <br>Добавить харварный генератор случайных байтоф, серт https://www.opennet.ru/openforum/vsluhforumID3/55024.html#11 Wed, 27 May 2009 21:40:47 GMT &gt;с переданными запускающим файловами дескрипторами процесс работать может, а других файлов открыть <br>&gt;не может <br><br>Чем open(/etc/passwd) хуже open(STDIN) <br> https://www.opennet.ru/openforum/vsluhforumID3/55024.html#10 Wed, 27 May 2009 21:39:25 GMT с переданными запускающим файловами дескрипторами процесс работать может, а других файлов открыть не может<br>