The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

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

27.05.2009 12:57

Dan Walsh и Eric Paris, участвующие в разработке SELinux, представили новый механизм для безопасного выполнения не испытывающих доверия приложений в Linux. Утилита sandbox позволяет выполнить программу с максимальным уровнем изоляции 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 раздела в качестве рабочей директории на лету.

  1. Главная ссылка к новости (http://lkml.org/lkml/2009/5/26...)
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/21913-sendbox
Ключевые слова: sendbox, chroot, limit, block, selinux
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (11) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 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 - нет.
     
     
  • 5.21, pavlinux (ok), 20:09, 28/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    т.е. предлагаешь через getc/putc работать ....


     

  • 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, и при этом, наверное, является наибольшей потенциальной дырой в системе…)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру