1.1, Анонимус (ok), 19:22, 27/05/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
великолепно! Ещё бы сделали чтоб можно было без особых манипуляций запустить программку в песочнице - например, если мне она нужна только один раз, то прописывать политики как-то лень.
| |
1.9, pavlinux (ok), 01:22, 28/05/2009 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
> # 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 мечта афтора!
Почти исключение - зомби, - ни хрена не делают, хотя числятся в списке процессов, как половина сотрудников НИИ или наша группа в институте :)
| |
|
2.10, szh (ok), 01:39, 28/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
с переданными запускающим файловами дескрипторами процесс работать может, а других файлов открыть не может
| |
|
3.11, pavlinux (ok), 01:40, 28/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>с переданными запускающим файловами дескрипторами процесс работать может, а других файлов открыть
>не может
Чем open(/etc/passwd) хуже open(STDIN)
| |
|
4.13, pavlinux (ok), 01:56, 28/05/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
А я придумал .....
Надо ещё написать утилитку 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-29052009.rsa -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-29052009.rsa -dx sha512
Естественно, сертификат на SSL соединение выдаётся на сервере.
Добавить харварный генератор случайных байтоф, сертифицированный ФСБ.
И ещё добавить PAX от grSecurity - и убится апстену.......
(to be continued...)
| |
|
5.18, triz0r (?), 13:10, 28/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>
># fd -i /etc/passwd -s https://keyserver.secretdomain.com/users/vasya/sanbox-29052009.rsa -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-29052009.rsa -dx sha512
>
>Естественно, сертификат на SSL соединение выдаётся на сервере.
>Добавить харварный генератор случайных байтоф, сертифицированный ФСБ.
>И ещё добавить PAX от grSecurity - и убится апстену.......
>
>(to be continued...)
Ага, а для связи с keyserver -использовать шифрованный канал - для получения ключа SSL, аутентификация через PKI, шифрование сессии - только симметричным ключом размером 4096. хеш ключа генерируется с привязкой к железу ...
Т.е. до запуска команды
# fd -i ...надо ещё парочку налабать :)
| |
5.19, User294 (ok), 13:43, 28/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>И ещё добавить PAX от grSecurity - и убится апстену.......
>(to be continued...)
Это как?! Necromancy is a forbidden art (c) :P
| |
|
4.20, Вова (?), 16:38, 28/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
для работы с файлом /etc/passwd необходим системный вызов open(/etc/passwd), для работы с stdin - нет.
| |
|
|
|
1.22, Thorn (??), 11:42, 29/05/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Наконец-то начали латать этот Решетинукс! Только поздно уже...
По идее, ЛЮБАЯ программа не должна вылезать за пределы своей директории, а всякие запросы к /dev/* осуществлять через системные сервисы (где и проверяются все пермишыны).
| |
|
2.23, HoverHell (ok), 13:07, 29/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Наконец-то начали латать этот Решетинукс! Только поздно уже...
>
>По идее, ЛЮБАЯ программа не должна вылезать за пределы своей директории, а
>всякие запросы к /dev/* осуществлять через системные сервисы (где и проверяются
>все пермишыны).
open('/dev/smth') тот же системный запрос позволяющий ту же регулировку прав :)
А вот open('/home/some1/.gnupg/secring.gpg') уже не выглядит так хорошо (если это делает не '/usr/bin/gpg'). Как и exec самого /usr/bin/gpg, хотя.
То есть говоря, для большей безопасности у одного пользователя должна быть (хотя бы!) возможность определять, к чему есть доступ определённых программ. Вроде того, как это делается для системных демонов.
(Только вот firefox у меня использует очень много всего включая gpg, и при этом, наверное, является наибольшей потенциальной дырой в системе…)
| |
|
|