Virtual eXecuting Environment

[slozovsk]

Спешу поделиться новостью Наконец решился выложить под GPL лицензией свою систему защиты Linux серверов. http://vxe.quercitron.com

Посетители Привета первые - с кем я делюсь этой радостной новостью

Поздравления принимаются наравне с комментариями

[Sabina]

Поздравления принимаются наравне с комментариями

Пока только поздравления:


Комментарии следуют ...

Сабина

[slozovsk]

Поздравления принимаются наравне с комментариями

Пока только поздравления:


Комментарии следуют ...

Сабина

Нууууу - замечательная картинка Спасибо, Сабина!

[Strannik223]

А можно чуть больше технических подробностей?
Как это реализовано: user mode kernel?
Как это соотносится с FreeBSD "jail" решением?

P.S. а вообще круто!

[f_evgeny]

Спешу поделиться новостью Наконец решился выложить под GPL лицензией свою систему защиты Linux серверов. http://vxe.quercitron.com

Посетители Привета первые - с кем я делюсь этой радостной новостью

Поздравления принимаются наравне с комментариями

Глянул одним глазком. Сразу возник вопрос, использует ли Ваша система UML?

[Michael Popov]

Performance overhead меряли ? Как ?

[slozovsk]

А можно чуть больше технических подробностей?
Как это реализовано: user mode kernel?
Как это соотносится с FreeBSD "jail" решением?

P.S. а вообще круто!

Основа сидит в kernel. В userspace утилитка для загрузки описаний VXED в ядро и система разработки (редактирования VXED) - в userspace, конечно.

Когда это делалось - jail, кажется, еще не было (могу ошибаться, конечно).

Быстренько посмотрел описание jail. Такое впечатление, что VXE более гибкая система:

1. Можно описать ограничения на доступ к любым ресурсам - поскольку можно лимитировать все syscalls.
2. Система построения Virtual Environment (аналог описания jail) - автоматизирована. А это очень важно. Любая программа пользуется такими ресурсами, что вы и не подозреваете - shared libaries и т.д. Описать это все - просто так из головы - очень сложно.
3. Похоже, что jail для ограничения доступа к файлам использует chroot (файловая система, это первое, что попалось; я, конечно, потом дочитаю)

Jail takes advantage of the existing chroot(2) behaviour to limit access to the file system name-space for jailed processes.

http://docs.freebsd.org/44doc/papers/ja ... l#section4

С chroot-ом много проблем.
1. Если уже установлена сложная система (Oracle, например) - засунуть ее в chroot - может быть очень непростой задачей.
В VXE икаких изменений в защищаемой системе делать не надо.
2. Что делать с файлами, которые используются разными подсистемами? Например - /etc/passwd, /etc/shadow? Что делать, если я хочу защитить POP сервер? Копировать все пароли в chroot? Муторная дополнительная работа + надо выявить все связи между подсистемами. Кто-то пароли меняет и их сразу надо копировать по всем chroot-ам?

[slozovsk]

Спешу поделиться новостью Наконец решился выложить под GPL лицензией свою систему защиты Linux серверов. http://vxe.quercitron.com

Посетители Привета первые - с кем я делюсь этой радостной новостью

Поздравления принимаются наравне с комментариями

Глянул одним глазком. Сразу возник вопрос, использует ли Ваша система UML?

Нет. VXE описывает ресурсы доступные подсистеме. Делается это в терминах разрешенных syscalls. Хотя возможны и более высокие уровни абстракции. Примером является ограничения доступа к файловой системе. В описании указывается, какие файлы доступны на чтение, запись, выполнение - и VXE сама лимитирует соответствующие syscalls (исходя из здравого смысла (моего) - поскольку, возможны варианты - файловых syscall-ов то много и как их ограничивать непонятно - я старался следовать правилам UNIX; кому нужна более точная настройка - может лимитировать отдельные syscalls (например, запретить работу с линками); звучит это очень сложно, но благодаря наличию средств автоматизации постороения описания конкретного VXED - все не так страшно; насколько мне известно, большинство конкурирующих систем страдают отсутствием автоматического построения jail (ну или, как там оно называется в конкретной системе);

[slozovsk]

Performance overhead меряли ? Как ?

Руки не дошли, хотя - дело хорошее. На сайте я написал соображения по поводу perfomance

VXE affects performance in following ways. If program runs outside any VXE, every syscall executes two assembler instructions more (checks if VXE is in effect for current process and jump if no). For every exec syscall a small C subroutine checks if there is a matching VXED already available in the kernel. For programs that run in VXE, a few lines of C code checks if parameter verification is needed. Some syscalls can be marked in VXED as uncheckable (for example, by default, read and write operations). And only the rest syscalls are checked by very small LISP functions. These functions located in VXED and can be easily observed by administrator.

Многие syscalls, которые имеет смысл ограничивать очень ресурсоемкие (open, например) - так, что небольшой довесок в виде проверки аргументов не должен сильно сказаться на производительности.

Второе соображение - security - важнее, чем perfomace. Если у вас есть сервер с хорошей perfomance, но его можно взломать... - как руководитель - я бы не спал ночами. Кроме того, что в случае взлома будет down time на восстановление (и перебой в обслуживании пользователей данного сервера, так еще и информацию могут украсть). (я сознаю, что высказался очень провокационно - понятно, что если в результате защиты сервер становится непригодным для использования - толку от такой защиты тоже нет).

Надо будет померять...

Могу поделиться историей - почему был создан VXE. В далеком 1998 году (когда я был в Одессе), наш Линкус сервер колокированный в Штатах - взломали. (конкретный взлом произошел по халатности наших ребят - они лазили на сервер, пытались запуститиь X-windows - у них не получалось, они убрали на время файрволл и забыли его вернуть).

И вот я в Одессе, а сервер в США - что делать? Попросили колокаторщиков проинсталлировать систему по новой, потом поставили свой софт (ssl туннель для TCP соединений - сами сделали - готовых решений в тот момент еще небыло). Клиентов несколько подвели да и сами нервы попортили.

Ну, вот - поставили мы все, включая файрвол - а спать то я спокойно не могу. Сервер не защищен - порты, по которым мы предоставляем сервис закрыть нельзя (25 - sendmail, например). В любой системе есть ошибки, а уж в sendmail проблем с безопасностью на тот момент - было вагон и маленькая тележка. И что делать? Полазил я по сети - ничего пригодного для защиты не было. Начал я думать - что же с этим можно сделать. Вспомнил, что на майнфреймах такой проблемы не было. Там все ресурсы описывались отдельно (DD описание (JCL), кто на ЕС-ках работал). Вот и все - остальное было делом техники.

Хотелось, чтобы администраторы могли безопасность настраивать так как они хотят без необходимости ковыряться в ядре. Ну и я не хотел все время в ядре что-то делать. По этому и засунул туда Lisp интерпретатор. Такого, по моему тоже никто еще не делал