Непревзойденный в плане подхода к обеспечению безопасности серверный 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
"Версия 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'ов - некоторые уже вошли пока мы "разрабатывали").
В целом понятно, но спасибо за пояснения. Поздравляю вас и нас с переходом Owl на 2.6. :-)
> Поздравляю вас и нас с переходом Owl на 2.6. :-)Спасибо за поздравление. Кстати, несмотря на наш выбор определенной ветки ядер, на Owl успешно собираются и Owl успешно работает под свежайшими ядрами 2.6 (и это не новость) - я на днях проверял с 2.6.31.6. Так что наши пользователи имеют выбор. Другое дело, что нам надо было выбрать определенную версию /usr/include/{linux,asm*} для сборок Owl userland. Если взять header'ы от того же 2.6.31.6, вместо предоставляемых нами, не соберется как минимум vzctl. ;-)
привет solar !
до сих пор под впечатление от твоего нора.может быть помнишь, когда то страшно давно, fido ru.hacker. Твой NOR hackme.
А мне запомнилась его 128 байтовая демка Cross, котороую он на конкурс в ru.demo.design лет 15 назад кидал :-)
>А мне запомнилась его 128 байтовая демка Cross ...Забавно, что такие вещи вспомнили здесь. Cross была другого участника конкурса. Моя была Highway. Но это не в тему.
А в тему - за Owl "стою" не только я. В частности, значительную часть работы после Owl 2.0 (да и до тоже) проделали Дмитрий Левин (известный также как один из ключевых разработчиков ALT Linux), Михаил Литвак, Дмитрий Хлебников и еще несколько человек (в том числе "не русские", хотя это в большей степени до 2.0). Проект небольшой, команда тоже, но всё же это не я один, и это важно.
2.6.18-128.2.1.el5.028stab064.8-owl0.2 -- детская болезнь, такое длинное наименование избыточно. Вполне достаточно 2.6.18-owl-r0648 :-) Уж поверьте... Живу на таком же ядре с 2006 года (саморощенный SLAX-like линукс на основе GETNTOO). Кстати, как у вас там с aufs дело обстоит -- используете ли и если да, то какую версию?
>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 для изменений) всерьез потребуется нам самим или станет стандартной функцией используемого ядра.
> В ближайших планах (вероятно, декабрь) - переход на "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-го марта.
По сути это голая операционка, а что будет с Непревзойденной безопасностью, если я начну устанавливать дополнительное ПО? Ставить все на виртуальные машины? (В смысле, контейнеры).
Разумеется, дополнительное ПО может привнести дополнительные уязвимости. От этого полностью не уйти и это надо учитывать (сисадмину).На 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) или же с соответствующими этой задаче программами.
А есть ли какие-то планы по интеграции 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, 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 не скажу, не смотрел подробно.
> А есть ли какие-то планы по интеграции 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.
А как на счет grsecurity pax?
>А как на счет 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 пока не пишу, предполагаю что этого в вопросе не было, да и время жалко, а короткие, но верные и полезные ответы у меня не получаются. ;-)
Спасибо, идеология прояснилась. Буду пробовать пока на VirtualBox.
> Буду пробовать пока на VirtualBox.Отлично. Пожалуйста, о результатах (отзывы, вопросы) - в owl-users. А можно и в комментарии здесь тоже. Нам реально нужны отзывы от пользователей.
У нас появилась инструкция по использованию OpenVZ контейнеров на Owl, на конкретном примере, как на установленной, так и на загруженной с CD/DVD системе (для тех кто хочет сначала "поиграться"):http://openwall.info/wiki/Owl/usage-examples/OpenVZ/getting-...
(Разумеется, можно и просто грузиться с файла-ISO'шки под эмулятором. Сами часто так делаем.)
Молодцы!С интересом прочитал новость и комментарии здесь.
