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
великолепно! Ещё бы сделали чтоб можно было без особых манипуляций запустить программку в песочнице - например, если мне она нужна только один раз, то прописывать политики как-то лень.
> # 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/users1. Утверждение: В sandbox запрещен доступ к работе с файлами!
2. В примере cut разрешилось записать в файл - STDOUT !!!
3. Работа с STDIN/STDOUT в экваквалентна работе с файлами.
4. В Unix - всё файлы, за исключением железа и напряжения в проводниках :)Как видим 2, 3 и 4 - ФАКТЫ, а 1 мечта афтора!
Почти исключение - зомби, - ни хрена не делают, хотя числятся в списке процессов, как половина сотрудников НИИ или наша группа в институте :)
с переданными запускающим файловами дескрипторами процесс работать может, а других файлов открыть не может
>с переданными запускающим файловами дескрипторами процесс работать может, а других файлов открыть
>не можетЧем open(/etc/passwd) хуже open(STDIN)
А я придумал .....Надо ещё написать утилитку 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...)
>[оверквотинг удален]
>
># 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 ...надо ещё парочку налабать :)
>И ещё добавить PAX от grSecurity - и убится апстену.......
>(to be continued...)Это как?! Necromancy is a forbidden art (c) :P
для работы с файлом /etc/passwd необходим системный вызов open(/etc/passwd), для работы с stdin - нет.
т.е. предлагаешь через getc/putc работать ....
Наконец-то начали латать этот Решетинукс! Только поздно уже...По идее, ЛЮБАЯ программа не должна вылезать за пределы своей директории, а всякие запросы к /dev/* осуществлять через системные сервисы (где и проверяются все пермишыны).
>Наконец-то начали латать этот Решетинукс! Только поздно уже...
>
>По идее, ЛЮБАЯ программа не должна вылезать за пределы своей директории, а
>всякие запросы к /dev/* осуществлять через системные сервисы (где и проверяются
>все пермишыны).open('/dev/smth') тот же системный запрос позволяющий ту же регулировку прав :)
А вот open('/home/some1/.gnupg/secring.gpg') уже не выглядит так хорошо (если это делает не '/usr/bin/gpg'). Как и exec самого /usr/bin/gpg, хотя.То есть говоря, для большей безопасности у одного пользователя должна быть (хотя бы!) возможность определять, к чему есть доступ определённых программ. Вроде того, как это делается для системных демонов.
(Только вот firefox у меня использует очень много всего включая gpg, и при этом, наверное, является наибольшей потенциальной дырой в системе…)