The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"В проект Owl добавлена поддержка OpenVZ и осуществлен перехо..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"В проект Owl добавлена поддержка OpenVZ и осуществлен перехо..."  +1 +/
Сообщение от opennews on 25-Ноя-09, 07:23 
Непревзойденный в плане подхода к обеспечению безопасности серверный Linux дистрибутив Owl (http://www.openwall.com/Owl/) осуществил переход (http://www.openwall.com/lists/announce/2009/11/23/1) на Linux ядро 2.6.x. Также в дистрибутив интегрирована поддержка технологии OpenVZ для создания изолированных контейнеров, в связи с чем в состав добавлены пакеты vzctl и vzquota. В качестве Linux ядра используется версия 2.6.18 с патчами от RHEL и поддержкой OpenVZ. Отражающие последние изменения ISO-образы  сформированы (http://www.openwall.com/Owl/) для архитектур x86 и x86-64.

URL: http://www.openwall.com/lists/announce/2009/11/23/1
Новость: http://www.opennet.me/opennews/art.shtml?num=24395

Высказать мнение | Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "версия ядра: скорее fork и стабильная ветка, чем 'с патчами'"  +/
Сообщение от solardiz on 25-Ноя-09, 07:23 
"Версия 2.6.18 с патчами ..." - это, хоть и правда, но очень условно. Если размер объединенного патча (10 MB под .bz2) сравним с размером ядра (40 MB под .bz2), какая это теперь версия?.. Номер у нее получается длинный - у нас она сейчас зовется 2.6.18-128.2.1.el5.028stab064.8-owl0.2. Сюда вошел номер версии ядра, от которой Red Hat'овцы fork'нули stable ветку для RHEL5, номер версии RHEL-патчей (трехзначный т.к. у них тоже ветки - эта одна из стабильных, на основе которой Red Hat выпускал официальные обновления RHEL), номер версии OpenVZ-патчей, и номер версии наших патчей (совсем мелких - на данный момент это всего 11 KB под .gz - да, килобайт).

Звучит страшно? А не стоит бояться. Это правда стабильная ветка (ну, по крайней мере в терминах Red Hat и OpenVZ, и относительно cutting-edge 2.6 ядер), включающая back-port'ы security fix'ов (а многие публикуемые сейчас уязвимости ядер 2.6.3x, кстати, в 2.6.18 просто отсутствовали, так что новых back-port'ов требуется и делается меньше, чем сейчас исправляется уязвимостей в 2.6.3x), некоторый security hardening (exec-shield, vm.mmap_min_addr и отвязка его от LSM - в свежих 2.6.3x это тоже есть, в исходном 2.6.18 не было), а также back-port'ы драйверов.

Названные мной 10 MB - это почти исключительно изменения между 2.6.18 и ядром из RHEL5, причем из них большая часть объема - это драйвера. Код OpenVZ - в пределах 10% от размера общего патча. Вот картинка, которая это поясняет:

http://wiki.openvz.org/Image:Kernel-loc-changes-compared-to-...

В ближайших планах (вероятно, декабрь) - переход на "2.6.18-164..." (как-бы с RHEL 5.3 на 5.4). В более отдаленных - на OpenVZ-патч на основе ядер из RHEL6, опять же с нашими мелкими патчами сверху, конечно (теми из них, которые еще не войдут в один из upstream'ов - некоторые уже вошли пока мы "разрабатывали").

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "версия ядра: скорее fork и стабильная ветка, чем 'с патчами'"  +/
Сообщение от Alex (??) on 25-Ноя-09, 10:37 
В целом понятно, но спасибо за пояснения. Поздравляю вас и нас с переходом Owl на 2.6. :-)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "версия ядра: скорее fork и стабильная ветка, чем 'с патчами'"  +/
Сообщение от solardiz on 25-Ноя-09, 12:03 
> Поздравляю вас и нас с переходом Owl на 2.6. :-)

Спасибо за поздравление. Кстати, несмотря на наш выбор определенной ветки ядер, на Owl успешно собираются и Owl успешно работает под свежайшими ядрами 2.6 (и это не новость) - я на днях проверял с 2.6.31.6. Так что наши пользователи имеют выбор. Другое дело, что нам надо было выбрать определенную версию /usr/include/{linux,asm*} для сборок Owl userland. Если взять header'ы от того же 2.6.31.6, вместо предоставляемых нами, не соберется как минимум vzctl. ;-)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

11. "версия ядра: скорее fork и стабильная ветка, чем 'с патчами'"  +/
Сообщение от demimurych email on 25-Ноя-09, 22:28 
привет solar !
до сих пор под впечатление от твоего нора.

может быть помнишь, когда то страшно давно, fido ru.hacker. Твой NOR hackme.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

12. "версия ядра: скорее fork и стабильная ветка, чем 'с патчами'"  +/
Сообщение от Аноним (??) on 25-Ноя-09, 23:03 
А мне запомнилась его 128 байтовая демка Cross, котороую он на конкурс в ru.demo.design лет 15 назад кидал :-)


Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

16. "команда разработчиков Owl"  +/
Сообщение от solardiz on 26-Ноя-09, 03:37 
>А мне запомнилась его 128 байтовая демка Cross ...

Забавно, что такие вещи вспомнили здесь. Cross была другого участника конкурса. Моя была Highway. Но это не в тему.

А в тему - за Owl "стою" не только я. В частности, значительную часть работы после Owl 2.0 (да и до тоже) проделали Дмитрий Левин (известный также как один из ключевых разработчиков ALT Linux), Михаил Литвак, Дмитрий Хлебников и еще несколько человек (в том числе "не русские", хотя это в большей степени до 2.0). Проект небольшой, команда тоже, но всё же это не я один, и это важно.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

13. "версия ядра: скорее fork и стабильная ветка, чем 'с патчами'"  +/
Сообщение от seyko email(??) on 26-Ноя-09, 00:24 
2.6.18-128.2.1.el5.028stab064.8-owl0.2 -- детская болезнь, такое длинное наименование избыточно. Вполне достаточно 2.6.18-owl-r0648 :-) Уж поверьте... Живу на таком же ядре с 2006 года (саморощенный SLAX-like линукс на основе GETNTOO). Кстати, как у вас там с aufs дело  обстоит -- используете ли и если да, то какую версию?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

15. "версия ядра: скорее fork и стабильная ветка, чем 'с патчами'"  +/
Сообщение от solardiz on 26-Ноя-09, 03:18 
>2.6.18-128.2.1.el5.028stab064.8-owl0.2 -- детская болезнь, такое длинное наименование избыточно. Вполне достаточно 2.6.18-owl-r0648 :-)

Спасибо за мнение. В userland пакетах мы такие длинные "номера" версий не используем, несмотря на то что в ряде случаев там тоже набор патчей из разных источников. В случае с ядром пока так в какой-то степени чтобы подчеркнуть для "новичков" что это далеко не 2.6.18 и сразу "ответить на вопросы" что именно. С другой стороны, я понимаю что все ответы в номер версии или имя файла все равно не уместить... К тому же, 128.2.1 оказывается не совсем верным, т.к. часть более новых Red Hat'овых патчей вошла в owl0.2, фактически доведя версию до 128.7.1, но OpenVZ'овый 064.8 при этом базировался на 128.2.1. Так что да, есть причины отказаться от такой длинной нумерации. Подумаем.

> Кстати, как у вас там с aufs дело обстоит -- используете ли и если да, то какую версию?

Пока не используем. Пока контейнеры на simfs. Может быть, позже, если будет значительный спрос или это (общие файлы и copy-on-write для изменений) всерьез потребуется нам самим или станет стандартной функцией используемого ядра.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

20. "версия ядра: скорее fork и стабильная ветка, чем 'с патчами'"  +/
Сообщение от solardiz on 25-Мрт-10, 14:03 
> В ближайших планах (вероятно, декабрь) - переход на "2.6.18-164..." (как-бы с RHEL 5.3 на 5.4).

С опозданием, но мы всё же это сделали. В ISO'шках за 23-е марта (под i686 и x86-64) ядро зовется 2.6.18-164.15.1.el5.028stab068.5-owl1 и включает патчи от Red Hat из -164.15.1, объявленного 16-го марта, и 028stab068.5 от OpenVZ, выпущенного 18-го марта.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "В проект Owl добавлена поддержка OpenVZ и осуществлен перехо..."  +/
Сообщение от Logo (ok) on 25-Ноя-09, 10:02 
По сути это голая операционка, а что будет с Непревзойденной безопасностью, если я начну устанавливать дополнительное ПО? Ставить все на виртуальные машины? (В смысле, контейнеры).
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "В проект Owl добавлена поддержка OpenVZ и осуществлен перехо..."  +2 +/
Сообщение от solardiz on 25-Ноя-09, 11:55 
Разумеется, дополнительное ПО может привнести дополнительные уязвимости. От этого полностью не уйти и это надо учитывать (сисадмину).

На Owl, риск от таких уязвимостей снижается hardening'ом базовой системы. Например, для каждого пользователя создается отдельный $TMPDIR каталог (средствами pam_mktemp) и, если программа использует переменную $TMPDIR, то уязвимости, связанные с некорректной работой с временными файлами, оказываются нейтрализованы (такие программы и уязвимости нам встречались). Другой пример - glibc с нашими изменениями при запуске SUID/SGID программ сбрасывает ряд переменных окружения, которые были бы небезопасны для самого glibc при "повторном" запуске какой-либо программы из уже запущенной. Это может "спасти", например, от атак на sudo (принципиально не входящий в Owl) при некоторых опасных его настройках.

Что, пожалуй, более важно и более эффективно, базовая система Owl (здесь я говорю о нашем userland'е) в большей степени разграничивает Unix-пользователей (а также псевдо-пользователей) чем многие другие дистрибутивы. У нас меньше SUID/SGID программ (а каждая такая программа представляет риск "локальных" атак), они меньше объемом, мы были осторожны в их выборе, и мы подвергли их аудиту и правке (см. слайды презентации об Owl). В итоге, если дополнительные программы запускать только под отдельными пользователями (которым эти программы нужны) или псевдо-пользователями (для сервисов), то возможная "компрометация" будет ограничена этими пользователями (их уровнем доступа).

Разумеется, уязвимости, позволяющие все же получить доступ другого пользователя или root'а на Owl, все же наверняка существуют - в ядре. Оно монолитное и слишком большое и сложное, чтобы их там совсем не было, сколько ни исправляй. Но на Owl, в сравнении с другими дистрибутивами, гораздо лучше ситуация с подобными уязвимостями в userland (возможно, что их нет и вовсе, если говорить об "активных" атаках, при том что "за ядро" у меня уверенность, увы, противоположная), да и из тех, что наверняка есть в ядре, значительная доля (возможно, бОльшая часть) недоступны для атак с Owl userland (не такие "расслабленные" права на /dev/*, нет авто-загрузки модулей ядра и т.п.)

Кстати, общедоступная SUID программа в стандартной установке осталась только одна - это ping. Ведь это не вещь первой необходимости на большинстве серверов и контейнеров, правда? Так что ее можно ограничить, сказав "control ping restricted". После этого на ping станет mode 700 - доступ только root'у (и эта настройка, кстати, будет сохраняться при обновлениях системы). Другие программы, такие как passwd и crontab, используют SGID под выделенные им группы, и доступ этих групп, без какой-либо другой уязвимости, не расширяется до root-доступа, благодаря нашим правкам этих программ и библиотек. Полный отказ от SUID-программ нейтрализует некоторые классы потенциальных уязвимостей в ядре.

И, наконец, да - контейнеры. В какой мере и в каких случаях их использовать - выбор сисадмина. Конкретный пример "из жизни" - несколько экземпляров разных wiki (один и тот же набор доп. программ - Apache, PHP, DokuWiki) на разных доменах "идут" в один контейнер (т.к. все равно потенциальные уязвимости общие). В то время как другой веб-сайт, не требующий PHP, размещается на том же сервере в другом контейнере. Для почты может быть создан еще один контейнер без доп. программ (Postfix, popa3d, procmail, Mutt входят в базовую поставку Owl) или же с соответствующими этой задаче программами.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "В проект Owl добавлена поддержка OpenVZ и осуществлен перехо..."  +/
Сообщение от Антон (??) on 25-Ноя-09, 12:28 
А есть ли какие-то планы по интеграции SELinux, AppArmor, TOMOYO ? Как вы вообще к таким технологиям относитесь и насколько по вашему мода по их добавлению в дистрибутивы оправдана ?

Еще было бы интересно услышать ваше мнение по поводу технологий повышения безопасности, представленных Google в Chromium OS.
http://www.chromium.org/chromium-os/chromiumos-design-docs/s...
http://sites.google.com/a/chromium.org/dev/chromium-os/chrom...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

7. "В проект Owl добавлена поддержка OpenVZ и осуществлен перехо..."  +/
Сообщение от Alex (??) on 25-Ноя-09, 12:49 
>А есть ли какие-то планы по интеграции SELinux, AppArmor, TOMOYO ? Как
>вы вообще к таким технологиям относитесь и насколько по вашему мода
>по их добавлению в дистрибутивы оправдана ?
>
>Еще было бы интересно услышать ваше мнение по поводу технологий повышения безопасности,
>представленных Google в Chromium OS.
>http://www.chromium.org/chromium-os/chromiumos-design-docs/s...
>http://sites.google.com/a/chromium.org/dev/chromium-os/chrom...

С SELinux пока вопрос скорее не к разработчикам Owl, а к разработчикам SELinux и OpenVZ. Так как пока они вместе не работают. Когда OpenVZ войдет целиком в mainstream ядро или хотя бы в RHEL6, можно расчитывать, что оно будет вместе работать. Про AppArmor и TOMOYO не скажу, не смотрел подробно.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

8. "В проект Owl добавлена поддержка OpenVZ и осуществлен перехо..."  +1 +/
Сообщение от solardiz on 25-Ноя-09, 13:23 
> А есть ли какие-то планы по интеграции SELinux, AppArmor, TOMOYO ?

Пока что планы "отрицательные", по нескольким причинам, включая несовместимость с OpenVZ (не то чтобы принципиальную, но это дополнительная работа, код, риск). Решение, что OpenVZ просто "не совместима" с LSM, было принято еще в конце 2005-го года не без моего участия. Вероятно, когда поддержка контейнеров в большей степени вольется в mainstream ядра, их поддержка в Owl будет "переключена" на этот включенный код. Вероятно, разработчики mainstream ядер сделают "ту" поддержку безопасно (по их мнению) совместимой с LSM и ответственность будет "на них". Тогда этот аргумент отпадет.

> Как вы вообще к таким технологиям относитесь и насколько по вашему мода по их добавлению в дистрибутивы оправдана ?

Теория хорошая. Но я бы приступал к внедрению таких технологий только сначала исчерпав стандартные возможности Unix в своей же "базовой системе". Когда система даже толком не использует обычные file permissions биты, привнесение вылезающих за рамки традиционной Unix-модели средств безопасности выглядит преждевременным. Я бы лучше понял, если бы это делалось небольшим сторонним "security vendor'ом" для "фиксированного" популярного дистрибутива (уж какой ущербный дистрибутив есть, а мы его "залатаем"), но когда это делает компания-автор дистрибутива, такая расстановка приоритетов выглядит для меня нелогичной (хотя я понимаю как это происходит - интересы конкретных специалистов, причем уважаемых мной людей, а маркетинг уже потом подхватывает).

Из нашего опыта, для компонентов "базовой системы" (да и не только) можно добиться очень неплохих результатов стандартными средствами Unix, если их использовать "по полной". А с внедрением в ядро компонентов для реализации контейнеров удается пойти еще дальше - например, свежие версии vsftpd (кстати, включенного в Owl) уже как-бы частично загоняют части себя в "контейнер" (в той степени, в которой конкретное Linux-ядро это умеет) - это уже несколько больше, чем просто chroot в /var/empty.

> Еще было бы интересно услышать ваше мнение по поводу технологий повышения безопасности, представленных Google в Chromium OS.

Я не в курсе деталей. Информация на сайтах вызывает у меня согласие, как и люди кто за этим стоит. Среди прочего, там речь идет о применении как раз средств поддержки контейнеров, кстати, вошедших в mainstream ядра не без участия разработчиков OpenVZ. Да, кстати, автор vsftpd нынче работает в Google, разумеется в security team.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

9. "В проект Owl добавлена поддержка OpenVZ и осуществлен перехо..."  +/
Сообщение от Daemontux (ok) on 25-Ноя-09, 16:04 

А как на счет grsecurity pax?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

17. "В проект Owl добавлена поддержка OpenVZ и осуществлен перехо..."  +/
Сообщение от solardiz on 26-Ноя-09, 04:18 
>А как на счет grsecurity pax?

Не планируется. При наличии времени (и, возможно, спонсора), есть потенциальный план делать свои hardening изменения и дополнения на основе ядер OpenVZ - как в код mainstream ядер, так и в код специфичный для OpenVZ. Например, возможность запретить отдельному контейнеру выполнять 32-битные или 64-битные системные вызовы, тем самым сокращая риск атак на ядро. Это лишь один пример, у меня есть список желаемых доработок такого рода. Вероятно, многое из этого сможет войти в upstream.

PaX - хорошая штука, и автор реально хороший специалист. Но есть причины PaX в Owl не интегрировать. Насколько я знаю, PaX не разрабатывается и не поддерживается для RHEL'овых ядер - т.е. портирование и поддержка были бы на нас (а это время и риск привнести баг или даже уязвимость - а PaX реально сложная штука, которую кроме его автора никто "до конца" не понимает - я слегка читал код, там есть очень много важных, но не комментированных деталей реализации, которые без знания "внешних обстоятельств", только из кода самого PaX, с уверенностью не понять - можно только предполагать что это так-то, вероятно, потому-то), либо же нам надо было бы на каких-то условиях договариваться с его автором.

PaX несет две основные функции - (1) предотвращение использования некоторых классов уязвимостей в user-space программах и (2) то же самое для в чем-то схожих классов уязвимостей в ядре. Что касается #1, то в RHEL-ядрах есть exec-shield. Он "слабее", но намного проще (меньше кода, нет замедления), и он уже есть. На процессорах с битом NX при сборке ядра с PAE, а также при 64-битном ядре, его эффективность схожа с PaX. (Правда, в моем списке есть и небольшая доработка exec-shield тоже.) Что касается #2, то пока мы ограничились vm.mmap_min_addr, что опять же "слабее", но гораздо "дешевле" PaX'а. (Кстати, эффект подобный PaX'овому UDEREF, с точки зрения безопасности, достигается "enterprise" сборкой RHEL-ядра с 4G/4G address space split, без всяких дополнительных патчей, но это слишком "дорого" с точки зрения производительности, поэтому это я отношу скорее к юмору. А еще можно просто использовать ядро Linux 2.0, с тем же эффектом (да, там было лучше), но это тоже юмор.)

Про остальной grsecurity пока не пишу, предполагаю что этого в вопросе не было, да и время жалко, а короткие, но верные и полезные ответы у меня не получаются. ;-)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

10. "В проект Owl добавлена поддержка OpenVZ и осуществлен перехо..."  +/
Сообщение от Logo (ok) on 25-Ноя-09, 16:29 
Спасибо, идеология прояснилась. Буду пробовать пока на VirtualBox.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

14. "В проект Owl добавлена поддержка OpenVZ и осуществлен перехо..."  +1 +/
Сообщение от solardiz on 26-Ноя-09, 03:02 
> Буду пробовать пока на VirtualBox.

Отлично. Пожалуйста, о результатах (отзывы, вопросы) - в owl-users. А можно и в комментарии здесь тоже. Нам реально нужны отзывы от пользователей.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

19. "В проект Owl добавлена поддержка OpenVZ и осуществлен перехо..."  +/
Сообщение от solardiz on 27-Ноя-09, 11:46 
У нас появилась инструкция по использованию OpenVZ контейнеров на Owl, на конкретном примере, как на установленной, так и на загруженной с CD/DVD системе (для тех кто хочет сначала "поиграться"):

http://openwall.info/wiki/Owl/usage-examples/OpenVZ/getting-...

(Разумеется, можно и просто грузиться с файла-ISO'шки под эмулятором. Сами часто так делаем.)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

18. "В проект Owl добавлена поддержка OpenVZ и осуществлен перехо..."  +/
Сообщение от phpcoder email(??) on 26-Ноя-09, 09:56 
Молодцы!

С интересом прочитал новость и комментарии здесь.


Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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