Спустя 5 лет с момента прошлого значительного выпуска представлена (http://www.openwall.com/lists/announce/2015/01/05/1) новая стабильная ветка Openwall GNU/*/Linux (http://www.openwall.com/Owl/ru/) (Owl) 3.1-stable, компактного дистрибутива GNU/Linux для серверов и виртуализированных окружений, ориентированного на обеспечение высокой безопасности. Owl 3.1-stable теперь будет поддерживаться в качестве стабильной ветки, а дальнейшая разработка продолжатся в ветке Owl-current (ftp://mirrors.kernel.org/openwall/Owl/current/). Поддержка ветки Owl 3.0-stable официально прекращена. Так как в ветке 3.1-stable представлены некоторые важные обновления, в том числе устранение уязвимости CVE-2014-9322 (http://www.opennet.me/opennews/art.shtml?num=41276), пользователям рекомендуется выполнить обновление (http://openwall.info/wiki/Owl/upgrade) до новой ветки. Доступны (ftp://mirrors.kernel.org/openwall/Owl/3.1-stable/iso/) ISO-образы (560Мб) с Live-системой и инсталлятором, которые подготовлены для архитектур i686 и x86-64. Также доступен (ftp://mirrors.kernel.org/openwall/Owl/3.1-stable/vztemplate/) шаблон для компоновки базовой системы контейнеров OpenVZ.Owl может использоваться как для создания высокозащищённых серверных систем, так и для создания базовой начинки изолированных контейнеров и организации работы контейнерной виртуализации на основе OpenVZ. В дистрибутиве по умолчанию применяются (http://www.openwall.com/Owl/ru/CONCEPTS.shtml) передовые методы обеспечения защиты, используются наиболее безопасные настройки (например, по умолчанию не поставляется программ с флагом suid) и поставляются только пакеты, заслуживающие доверия и прошедшие аудит исходного кода. Кроме готовых бинарных пакетов, предоставляются удобные средства для пересборки пакетов из исходных текстов (make buildworld (http://www.openwall.com/Owl/ru/BUILD.shtml)) и формирования iso-образа или начинки виртуального окружения. Развиваемые проектом варианты пакетов могут использоваться в RHEL и Fedora Linux.
В новой ветке (http://www.openwall.com/Owl/CHANGES-3.1.shtml):
- Осуществлён переход на ядро Linux 2.6.18-400.el5.028stab117.2 со встроенной поддержкой OpenVZ, основанное на ядре из состава RHEL 5.11 (в Owl 3.0 использовалось ядро из RHEL 5.5).- При сборке пакетов по умолчанию включены опции "-Wl,-z,relro" и "-Wl,-z".
- Число создаваемых устройств /dev/sd* увеличено с 8 до 16.
- В пакет owl-startup добавлена поддержка VLAN.
- Для сокращения размера базовой системы для дублирующихся в пакетах файлов и данных с параметрами часовых поясов задействованы жесткие ссылки.
- Вместо /bin/sh для интерактивного сеанса задействован /bin/bash;
- Добавлены пакеты: usbutils с типовыми утилитами для USB, usb_modeswitch и usb_modeswitch-data для работы с многорежимными USB-устройствами (например, для переключения 3G-модема в режим накопителя), а также пакеты libusb1 и libusb-compat с libusb 1.0 и библиотекой для совместимости со стеком libusb 0.1;
- Добавлен пакет vconfig для управления созданием устройств 802.1q VLAN;
- Добавлены пакеты ethtool и bridge-utils для тонкой настройки Ethernet-устройств и управления сетевыми мостами;
- Добавлена утилита PV ("Pipe Viewer") для наглядной оценки прогресса передачи данных через неименованный канал;- В ядре и утилите ping добавлена поддержка не-raw ICMP сокетов;
- В shadow-utils в /etc/login.defs добавлены опции USERNAME_RELAXED и GROUPNAME_RELAXED, допускающие использование символов в верхнем регистре в именах пользователей и группах.
- В crypt_blowfish добавлена поддержка префикса "$2b$", используемого в OpenBSD 5.5+.
- В пакете iptables по умолчанию запрещён резолвинг имён при выполнении команды "service iptables status";- Обновлены версии программ, в том числе GnuPG 1.4.18, OpenSSL 1.0.0m, Strace 4.8, John the Ripper 1.8, xinetd 2.3.15, binutils 2.23.51.0.1, tcsh 6.18.01, syslinux 4.05, lftp 4.3.6, gcc 4.6.3, bash 3.1pl23, crypt_blowfish 1.2, iproute2 2.6.38, nmap 5.51, vsftpd 2.3.4, e2fsprogs 1.41.14, tzdata 2014i.
URL: http://www.openwall.com/lists/announce/2015/01/05/1
Новость: http://www.opennet.me/opennews/art.shtml?num=41394
При сборке пакетов по умолчанию включены опции "-Wl,-z,relro" и "-Wl,-z"
"эпический вин" и как относится к безопасности не ясно.
Тут все расписано https://wiki.debian.org/Hardening
> "эпический вин" и как относится к безопасности не ясно.А ты попробуй hardening-check /your/executable - узнаешь для себя много нового.
> и "-Wl,-z":facepalm:
штабильность! ©> Осуществлён переход на ядро Linux 2.6.18
> штабильность! ©
>> Осуществлён переход на ядро Linux 2.6.18С предыдущего, которое тоже "2.6.18" и тоже разве что по надписи на борту. Вы вообще читаете перед тем, как писать?..
это уже не просто консерватизм, а диагноз...
>а диагноз...Конечно! Твой рогрессивизм же не межет быть диагнозом. Конечно, нет-нет!!
> это уже не просто консерватизм, а диагноз...Ну так давно известно что самая безопасная система - та которой никто не пользуется. Для надежности желательно чтобы она еще и не загружалась. На случай если кто-то вдруг додумается попробовать включить компьютер.
Как это сочетать
ориентированного на обеспечение высокой безопасности и Вместо /bin/sh для интерактивного сеанса задействован /bin/bash...
всё просто: фраза "Owl может использоваться как для создания высокозащищённых серверных систем, ..." не говорит, каким именно образом он должен использоваться.
Возможно, диск с дистрибутивом надо подкладывать куда-то под серверную стойку...
> Вместо /bin/sh для интерактивного сеанса задействован /bin/bash...Я сначала даже не понял откуда это взялось, но потом нашел у нас в CHANGES-3.1 запись, которая могла быть так интерпретирована. На самом деле, в ней речь шла об изменении имени шелла (а не самого шелла) при работе с LiveCD, чтобы включалась цветная выдача в команде ls. А bash запускался и до и после этого изменения. В качестве альтернативы в Owl есть tcsh. Иронию насчет bash'а и его излишней функциональности я понимаю и принимаю:
http://www.openwall.com/presentations/ZeroNights2014-Is-Info...
http://www.openwall.com/presentations/ZeroNights2014-Is-Info...Разумеется, Shellshock в Owl 3.1-stable исправлен. Но ирония осталась, да и раньше была.
>[оверквотинг удален]
> нас в CHANGES-3.1 запись, которая могла быть так интерпретирована. На самом
> деле, в ней речь шла об изменении имени шелла (а не
> самого шелла) при работе с LiveCD, чтобы включалась цветная выдача в
> команде ls. А bash запускался и до и после этого изменения.
> В качестве альтернативы в Owl есть tcsh. Иронию насчет bash'а и
> его излишней функциональности я понимаю и принимаю:
> http://www.openwall.com/presentations/ZeroNights2014-Is-Info...
> http://www.openwall.com/presentations/ZeroNights2014-Is-Info...
> Разумеется, Shellshock в Owl 3.1-stable исправлен. Но ирония осталась, да и раньше
> была.То есть переход на что-то полегче в /bin/sh и bash как login shell как в Дебиане не планируете?
> То есть переход на что-то полегче в /bin/sh и bash как login shell как в Дебиане не планируете?Четких планов на этот счет нет. (Нам бы по более важным вопросам определиться с будущим проекта.) Если bash всё равно останется в Owl, то добавление какого-то еще шелла лишь увеличивает суммарное количество потенциальных уязвимостей - возможно, не в конкретных установленных системах, но в дистрибутиве, а значит и с точки зрения его поддержки и нами и сисадминами. Тот же dash в Debian вполне вероятно помог спасти от Shellshock отдельные сервисы и даже системы, но для сисадминов работы было не меньше так как заранее (без затрат времени на анализ) было не понять не уязвим ли какой-либо сервис на конкретной системе через запуск bash откуда-то еще (не как login shell) - так что системы всё равно следовало обновлять все. Также, Shellshock - это (пока?) один такой пример за ~25 лет. Да, в bash много "лишнего", но для безопасности важен attack surface. А так ли уж больше attack surface в bash с полностью исправленным Shellshock (включая prefix/suffix patch от Florian'а, что исключает парсер из атак через произвольные переменные окружения), чем в том же dash? Возможно, да, но не проанализировав control и data flow в том и другом, я не уверен. Делать предположения по общему объему кода можно (в целом для большого количества различных шеллов положительная корреляция объема кода и attack surface должна быть), но в отдельном случае можно и ошибиться. Не хотелось бы принимать решения не изучив вопрос всерьез, но и не хотелось бы тратить значительное время на не очень важный для проекта вопрос. (Да, у меня опять вышел слишком длинный ответ.)
> Shellshock - это (пока?) один такой пример за ~25 лет.А это потому что все это скриптовое болото писаное левой пяткой никто не пробовал палочкой тыкать и это судя по всему была одна из первых попыток покормить скрипты работающих с внешними данными черти чем. Судя по результативности, когда на половине систем DHCP сервер может рута получить нахаляву - теперь внимания таким атакам будет больше.
> Да, в bash много "лишнего", но для безопасности важен attack surface.
Как по мне так куча скриптятины писаной без оглядки на интенсивную бомбардировку недоверяемыми данными, скомпонованными недружелюбно - похоже на целое отдельное минное поле. Большинство авторов скриптов при их написании элементарно не думает что вон те данные - приходят от ремотных систем и могут содержать что угодно.
> А так ли уж больше attack surface в bash с полностью исправленным Shellshock
Я бы сказал что в целом вываливание скриптятины писаной абы кем и абы как и потом кормление этого барахла внешними данными - выглядит как довольно стремное начинание. Вообще в целом. Шелл интерпретаторы весьма фичасты и сами по себе не создавались для работы с недоверяемыми входными данныи. А скрипты всегда были средством системной автоматизации. А не линией обороны. А тут всякие умники додумались через скрипты какие-нибудь параметры DHCP передавать. При том что туда DHCP может пхать что угодно.
Я думаю что вас (и нас) будет ждать изрядно неприятных сюрпризов.
>> Shellshock - это (пока?) один такой пример за ~25 лет.
> А это потому что все это скриптовое болото писаное левой пяткой никто не пробовал палочкой тыкатьДа нет, в скриптах уязвимости то и дело находят. И в bash, так скажем, особенности бывали, хотя и на удивление мало (известных) - лет 15 назад была история с обработкой символа '\xff' в скриптах. Но Shellshock выделяется тем, что обрабатывались произвольные переменные окружения, bash'у и конкретным скриптам не предназначенные, в результате чего уязвимым оказался запуск бинарных программ через "bash -c", system(), popen() и т.д. даже при отсутствии скриптов (в полном смысле).
> Да нет, в скриптах уязвимости то и дело находят.И почему я не удивлен? :)
А шеллшок выделяется тем что показал что
1) Нефиг пихать стремные фичи "чтоб было". Идея как-то сильно кастомно обрабатывать переменные окружения - это по любому хорошая заявка на залет.
2) Это же касается и иных входных данных. В шелскриптах вечный гемор с эскейпингом и специальной обработкой кучи всего. Если скриптам отдавать хоть какие-то данные, приезжающие с недоверяемых внешних систем - там целое поле для грабель. А скриптеры к тому же очень редко думают о таком развитии ситуации.
>Число создаваемых устройств /dev/sd* увеличено с 8 до 16.
>vconfig
>Linux 2.6.18-400.el5.028stab117.2Ностальжи.
Десктоп параноика
Десктоп параноика, батенька, это, например, Qubes OS. Ну или более просто, как у меня. Основная ОС в виртуальной машине с проброшенной видеокартой. И вида также, чтобы лишнего ничего не сделала. Как-то так:
[root@localhost domains]# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1024 4 r----- 603.8
ubuntu 1 4352 4 r----- 3586.2
win8 2 4096 2 -b---- 22347.1
webdavserver 3 512 1 -b---- 162.5
[root@localhost domains]#
Батенька в винде любит посидеть? :)
Только поиграть :)
> Десктоп параноикаДесктоп с ядром 2.6.18? Ну... если запускать это на той же машине что жидитоба реактос - тогда наверное нормально.
старовато ядрышко, безопасность видимо на самом первом плане!
Новые эксплойты делаются под современный софт и новые ядра.
Очень оригинальный защитный ход.
> Новые эксплойты делаются под современный софт и новые ядра.
> Очень оригинальный защитный ход.Понабежали школьники, не знающие про RHEL.
> Понабежали школьники, не знающие про RHEL.Так нынче рхел 7 уж вышел. А это из пятого еще...
>Новые эксплойты делаются под современный софт и новые ядра.Очень оригинальный защитный ход.
Security by obscurity?
Старовато, да. Особенно учитывая предстоящий в феврале EOL этой ветки в проекте OpenVZ - видимо, дальше самые важные фиксы нам придется тянуть в Owl 3.1-stable из RHEL5 самим, или перейти на OpenVZ ветку на основе RHEL6 или RHEL7 даже в нашей stable-ветке.А что касается безопасности, реальность такова что ядро Linux в целом в плохом состоянии, и выбор ветки (из поддерживаемых) тут мало поможет. Оно большое (и монолитное), а hardening-изменения продвигаются в него сложно. Оставаясь на более старой поддерживаемой Red Hat'ом ветке, мы убавляем частоту относящихся к нашей сборке обнаруживаемых и публикуемых критичных уязвимостей. Каждая новая уязвимость в свежем mainline зачастую отсутствует в RHEL6, и с еще большей вероятностью - отсутствует в RHEL5. Когда же критичная уязвимость, документированная как таковая, присутствует в RHEL, Red Hat выпускает фикс для всех поддерживаемых веток. При таком подходе опасность представляют silent fixes в mainline (и, соответственно, атаки с использованием извлеченной оттуда но не опубликованной информации об уязвимостях), но т.к. если мы хотим OpenVZ, mainline (и grsecurity) для нас не вариант, то выбор оказывается между разными ветками RHEL/OpenVZ, и с точки зрения безопасности на данный момент RHEL5 слегка выигрывает у RHEL6 и RHEL7 (но это будет меняться). Использование RHEL5/OpenVZ по крайней мере позволяет обновлять ядра на серверах не так часто, как это приходилось бы делать с более новыми версиями.
А кому наша интеграция OpenVZ (несколько устаревшая, да) не нужна - могут использовать Owl userland с любым более новым ядром, в том числе свежим grsecurity.
Ничего хорошего, конечно. Я считаю ядро самой уязвимой частью Owl, какую ветку/версию ядра мы бы ни выбрали.
Тут кто-то упомянул наличие/отсутствие эксплойтов под разные ядра. Уточню: выше я говорю именно про сами уязвимости (и их наличие или отсутствие), а не про эксплойты.
От платных эксплойтов вас и старое ядро не спасет....
На самом деле мы (разработчики) не считаем выход Owl 3.1-stable важной новостью в масштабах OpenNet. ;-) Я слегка удивлен здесь эту новость видеть (сам бы не публиковал). (По-моему, например, выход JtR 1.8.0-jumbo-1, включающий 4800+ коммитов относительно предыдущего jumbo-релиза, был более значим для широкой аудитории. Но о нем здесь новости не было. Возможно, мне следовало ее запостить.)За четыре года с выхода Owl 3.0, мы в основном занимались другими проектами, поэтому в Owl и сделано так мало - но так как проект не объявлен завершенным, пользователи вправе ожидать хотя бы самые необходимые обновления с исправлением уязвимостей, и мы такие обновления предоставляем - теперь в новой ветке, включающей также и те немногие и небольшие улучшения, что мы всё-таки внесли в Owl-current за это время. Создание новой ветки позволит внести в Owl-current менее консервативные изменения, при этом не потеряв нечаянно достигнутую стабильность current'а на лето 2014 (момент создания ветки 3.1). Об этом пользователей надо было уведомить, отсюда и анонс в наши списки рассылки и Twitter @Openwall.
Насчет пользы от и возможного будущего Owl, я недавно высказал некоторые мысли здесь: http://www.openwall.com/lists/owl-users/2014/12/30/1
Это действительно хорошая новость. Также, как и JTR jumbo. Последнего заждались, да)
solardiz, новости о jtr из первых рук были бы интересны. Для людей не подписанных на рассылки (я отписался пару лет тому назад), но желающих быть в курсе в общих чертах о происходящем было бы удобно. Я бы хотел видеть эти новости на opennet. Так что, если не тяжело, хотя бы пару строк в mini-новости не плохо бывало бы тиснуть касательно новых jambo.C уважением за труды.
> solardiz, новости о jtr из первых рук были бы интересны. Для людей
> не подписанных на рассылки (я отписался пару лет тому назад), но
> желающих быть в курсе в общих чертах о происходящем было бы
> удобно. Я бы хотел видеть эти новости на opennet. Так что,
> если не тяжело, хотя бы пару строк в mini-новости не плохо
> бывало бы тиснуть касательно новых jambo.Не тяжело, но я всё же не стану каждое обновление jumbo анонсировать здесь. Это было бы спамом, учитывая что разных открытых проектов много. Советую подписаться на наш список announce - там очень низкий трафик - гораздо ниже, чем в john-users и john-dev. За почти 15 лет существования списка - всего 199 сообщений. Это примерно одно в месяц.
http://www.openwall.com/lists/announce/
Думаю, это как раз то, что нужно, чтобы "быть в курсе в общих чертах о происходящем". А наши новости на OpenNet раз в месяц - это было бы слишком часто.
Конечно. Ключевое слово systemd - отсутствует же.
> На самом деле мы (разработчики) не считаем выход Owl 3.1-stable важной новостью
> в масштабах OpenNet. ;-)Да уж поважней многого.
> (По-моему, например, выход JtR 1.8.0-jumbo-1, включающий 4800+ коммитов
> относительно предыдущего jumbo-релиза, был более значим для широкой аудитории.
> Но о нем здесь новости не было. Возможно, мне следовало ее запостить.)...или даже следует :-)
> Насчет пользы от и возможного будущего Owl, я недавно высказал некоторые мысли здесь:
> http://www.openwall.com/lists/owl-users/2014/12/30/1Интересно.
"As to contributing to mainstream distros, I don't mind, but frankly I don't feel our userland security hardening enhancements are of as much value when mixed with a lot of other stuff in a distro like Fedora or Ubuntu." -- с другой стороны, на них свет клином не сошёлся и есть места, куда control(8) тащить просто не надо...
"For example, when Mandriva went to use our tcb [...]" -- вот это проворонил.
"Having our approaches adopted by multiple distros also side-steps the issue of systemd. The distros may vary in this aspect." -- а есть где-то подробнее? Вспомнилось http://www.opennet.me/opennews/art.shtml?num=39050 и нашлось http://comments.gmane.org/gmane.linux.openwall.devel/467 (2012).
> ...или даже следует :-)Здесь есть какие-то "правила" о (не) публикации "старых новостей"? Пока что я видел здесь "старые новости" в случаях, когда тему снова подняли и активно обсуждают где-то еще (например, так было с новостью о проблемах с DRAM, когда ее подняли в LKML).
> "Having our approaches adopted by multiple distros also side-steps the issue of
> systemd. The distros may vary in this aspect." -- а
> есть где-то подробнее?Наши планы по systemd в Owl? Пока никаких. Но у нас нашелся один ключевой разработчик, выступающий за systemd - см. раньше в том же треде в owl-users. На данный момент, я вижу интеграцию systemd в первую очередь как способ растерять/"прогнать" часть сообщества, что, конечно, является аргументом против systemd. Думаю, отсутствие systemd в Owl не будет восприниматься сторонниками systemd так же болезненно. Если нам потребуется какая-то совместимость с пакетами из других дистрибутивов, завязанными на systemd, возможно мы попробуем ее обеспечить без перехода на systemd.
> На данный момент, я вижу интеграцию systemd в первую очередь как способ
> растерять/"прогнать" часть сообщества, что, конечно, является аргументом
> против systemd.А какие приводятся технические аргументы? На localhost systemd нет в силу характерных методов его "продвижения" (и для меня этого достаточно даже без увеличения поверхности атаки "низов" системы), но интересно, как у коллег.
PS: с Рождеством!
> А какие приводятся технические аргументы?Все, приведенные именно в контексте разработки Owl, есть в том треде в owl-users. Я лучше не стану пытаться их пересказать. В целом, вопрос сводится к тому насколько далеко или близко к mainstream'у Owl должен быть. По-моему, начиная с какой-то степени приближенности к mainstream'у Owl теряет смысл как самостоятельный проект. Но никто точно не скажет где именно проходит эта грань.
Кстати, взяв Linux, а не что-то изначально лучшее для безопасности с точки зрения архитектуры и/или объема кода, мы уже в какой-то степени пошли на поводу у mainstream'а. На тот момент (1999-2000 год) это было связано с тем, что эта ниша выглядела свободной и нуждающейся в новом проекте. Думаю, подобные рассуждения (но, возможно, с другими выводами) могут быть применены и сейчас, для принятия решений о будущем проекта.
>> А какие приводятся технические аргументы?
> Все, приведенные именно в контексте разработки Owl, есть в том треде в owl-users.В этом? -- http://www.openwall.com/lists/owl-users/2014/12/21/2
> В целом, вопрос сводится к тому насколько далеко или близко к mainstream'у Owl должен
> быть. По-моему, начиная с какой-то степени приближенности к mainstream'у Owl теряет
> смысл как самостоятельный проект. Но никто точно не скажет где именно
> проходит эта грань.Размышлял над этими вопросами ещё со времён живого ASPLinux; кое-что получилось и изложить: http://vimeo.com/23522095 (но там долго и нудно, со всеми вводными).
> Думаю, подобные рассуждения (но, возможно, с другими выводами) могут
> быть применены и сейчас, для принятия решений о будущем проекта.Недавно на OS Day узнал о проекте embox -- одним из важных моментов при целеполагании была возможность вычитки полного состава исходников ОС, а также модульность вплоть до "нужен POSIX -- включаем подсистему"; возможно, и Вам либо коллегам покажется интересным.
>>> А какие приводятся технические аргументы?
>> Все, приведенные именно в контексте разработки Owl, есть в том треде в owl-users.
> В этом? -- http://www.openwall.com/lists/owl-users/2014/12/21/2Да, в этом треде (в сообщениях от galaxy@).
> Но о нем здесь новости не было. Возможно, мне следовало ее
> запостить.)Было бы неимоверно круто если бы вы это делали. Я иногда посматриваю на него, но сильно реже чем следовало бы. А хорошая софтина.
Заодно можно наверное было бы потестить оным на глючность опенсорсный вычислительный стек. Поблевать^W наколотить баги в багтрекер и посмотреть кто, сколько и где выжимает :).
>Добавлена утилита PV ("Pipe Viewer") для >наглядной оценки прогресса передачи >данных через неименованный канал;Какие данные передаются через пипец, например?
>>Добавлена утилита PV ("Pipe Viewer") для
>>наглядной оценки прогресса передачи
>>данных через неименованный канал;
> Какие данные передаются через пипец, например?Например, удобно с длинным dd(1) заместо размахивания сигналами и прикидки в уме.
А systemd будет?
Всенепременно. C ядром 2.6.18, да.
> А systemd будет?ненужно
не понял, а зачем этот древний vconfig?
разве "ip link add link eth0 name eth0.123 type vlan id 123" не торт?
vconfig add eth0 123
И что? Типа, короче? Тю!# cat my_vconfig
#!/bin/sh
usage() { echo "usage: `basename $0` (add|del) if_name vlan_id" ; }
[ $# -lt 3 ] && usage && exit 1
case $1 in
add)
ip link add link $2 name $2.$3 type vlan id $3
;;
del)
ip link set $2.$3 down && ip link del $2.$3
;;
*)
usage ; exit 1
;;
esac
> не понял, а зачем этот древний vconfig?Legacy. По сути уже не нужен. Если проектом снова заняться всерьез, надо бы переписать скрипты на iproute2.
Я смотрел ранее openwall, и как это ни странно меня больше всего заинтересовало переведение shadow на tcb, но решение какое то не полное, сделано только для shadow, а для passwd group gshadow нет. У вас собираются это доделывать?
> Я смотрел ранее openwall,<nitpick>
JFYI, Openwall - это наша команда. У нас несколько своих проектов, а также поддержка некоторых ресурсов для более широкого сообщества (в частности, список рассылки oss-security) и работы для наших клиентов. Owl - один из проектов, но не основной (мы не выделяем какой-либо проект как основной).
</nitpick>> и как это ни странно меня больше всего заинтересовало переведение shadow на tcb,
Не странно. Это один из компонентов, требовавшихся для ухода от SUID root программ, что мы и сделали. Наша реализация tcb также применяется в ALT Linux и Mandriva/Mageia, но без их полного ухода от SUID root в поставке по умолчанию это имеет меньший эффект для безопасности системы, чем в Owl.
> но решение какое то не полное, сделано только для shadow, а для passwd group gshadow нет. У вас собираются это доделывать?
Ой. А что там доделывать, и зачем? Раскидать passwd на кучу мелких файлов "для красоты"? Нет, для безопасности это не нужно. Аналогично с group. Для отказа от SUID root на команде passwd (и chage) достаточно было раскидать shadow.
С gshadow вопрос сложнее: тем очень немногим, кто знает о возможности поставить пароль на группу и этим пользуется, да еще и не от root'а, сейчас приходится сначала выполнить команду "control gpasswd wheelonly" или даже "control gpasswd public", при этом получив обратно SUID root на программу gpasswd. Это плохо. Мы могли бы попытаться это решить раскидав gshadow на файлы с администраторами групп в качестве владельцев. Но при этом останется вопрос как этими группами потом пользоваться? Всё равно команда newgrp, которую для этого потребовалось бы включить тем же control'ом, потребовала бы SUID root для переключения группы, либо патча в ядро, чтобы какие-то переключения групп работали с привилегиями, не эквивалентными root'у. Таким образом, мы получили бы либо недоделку, либо неоправданно сложную (и поэтому опасную) конструкцию. И всё ради возможности о которой мало кто знает и совсем мало кто пользуется. К этому можно добавить еще и принципиальные риски, связанные с использованием newgrp из-под пользователя. Поэтому мы поступили проще и поставляем gpasswd и newgrp доступными только root'у, и control-файлы для тех немногих, кто хочет эту возможность включить (на свой риск).
Так что нет, мы считаем tcb доделанным.
>[оверквотинг удален]
> Не странно. Это один из компонентов, требовавшихся для ухода от SUID root
> программ, что мы и сделали. Наша реализация tcb также применяется в
> ALT Linux и Mandriva/Mageia, но без их полного ухода от SUID
> root в поставке по умолчанию это имеет меньший эффект для безопасности
> системы, чем в Owl.
>> но решение какое то не полное, сделано только для shadow, а для passwd group gshadow нет. У вас собираются это доделывать?
> Ой. А что там доделывать, и зачем? Раскидать passwd на кучу мелких
> файлов "для красоты"? Нет, для безопасности это не нужно. Аналогично с
> group. Для отказа от SUID root на команде passwd (и chage)
> достаточно было раскидать shadow.Чесно говоря я так исчитал что это логичный следующий шаг, во всяком случае для смены shell home и gecos не надо suid
>[оверквотинг удален]
> останется вопрос как этими группами потом пользоваться? Всё равно команда newgrp,
> которую для этого потребовалось бы включить тем же control'ом, потребовала бы
> SUID root для переключения группы, либо патча в ядро, чтобы какие-то
> переключения групп работали с привилегиями, не эквивалентными root'у. Таким образом, мы
> получили бы либо недоделку, либо неоправданно сложную (и поэтому опасную) конструкцию.
> И всё ради возможности о которой мало кто знает и совсем
> мало кто пользуется. К этому можно добавить еще и принципиальные риски,
> связанные с использованием newgrp из-под пользователя. Поэтому мы поступили проще и
> поставляем gpasswd и newgrp доступными только root'у, и control-файлы для тех
> немногих, кто хочет эту возможность включить (на свой риск).Ну уход от setuid может быть планвным через setgid. Например для gshadow файлов 660 admingroup:root и бинарник setgid для группы root
> Так что нет, мы считаем tcb доделанным.
Если у меня будут силы и время может я форкну вашу либку :-)
> для смены shell home и gecos не надо suidАх да, chfn и chsh у нас сейчас поставляются ограниченными только для root'а. Разбивка /etc/passwd помогла бы сделать их снова доступными пользователям, при этом избежав SUID'ов. Но как-то спроса нет. Да и возможность изменения shell и GECOS пользователями - это дополнительный источник untrusted input для многих программ, а значит и дополнительный риск. Что касается home'а, его и традиционно пользователи сами менять не могли, так что привносить такую возможность - еще более опасно. К тому же, потребуется сохранить и какой-либо недоступный пользователю для записи файл или файлы для хранения UID и GID (и, наверное, home - по упомянутой причине). В целом, этот путь выглядит сомнительным и почти не нужным.
Есть еще тема удаленного определения (не)существующих имен пользователей через timing-атаки. Сейчас наш tcb и наши патчи в конкретные сервисы, такие как модификация OpenSSH в Owl, пытаются снизить утечки через время ответа, но не устраняют их полностью. Вычисляется хеш пароля даже если пользователь с таким именем отсутствует (к сожалению, при наличии в системе хешей с разными настройками, эффект от этого подхода получается гораздо меньше). Разбивка shadow здесь может чуть-чуть помогать: время поиска нужной строки не зависит от ее номера, как при традиционном /etc/shadow, но всё еще зависит от особенностей файловой системы.(*) Аналогично чуть-чуть улучшить ситуацию могла бы разбивка /etc/passwd и др., но пока у нас планов бороться с этими утечками более серьезно нет (особенно учитывая упомянутую проблему при разных типах/настройках хешей, а также небольшие утечки в сервисах, длине строк, записываемых в логи, и т.п., что не так просто и не так хорошо "исправлять").
(*) http://blog.wallarm.com/post/69598321538/timing-attacks-agai...
http://2013.zeronights.org/includes/docs/Ivan_Novikov_-_File...
>[оверквотинг удален]
> файлов "для красоты"? Нет, для безопасности это не нужно. Аналогично с
> group. Для отказа от SUID root на команде passwd (и chage)
> достаточно было раскидать shadow.
> С gshadow вопрос сложнее: тем очень немногим, кто знает о возможности поставить
> пароль на группу и этим пользуется, да еще и не от
> root'а, сейчас приходится сначала выполнить команду "control gpasswd wheelonly" или даже
> "control gpasswd public", при этом получив обратно SUID root на программу
> gpasswd. Это плохо. Мы могли бы попытаться это решить раскидав gshadow
> на файлы с администраторами групп в качестве владельцев. Но при этом
> останется вопрос как этими группами потом пользоваться? Всё равно команда newgrp,Да я забыл, вы правы, newgrp может только root, это setcap если без suid.
Что-то тут с группами мутно и это с самого начала unix. Ядро само не читает groups и gshadow. Этот setuid наверное не убрать никогда.>[оверквотинг удален]
> которую для этого потребовалось бы включить тем же control'ом, потребовала бы
> SUID root для переключения группы, либо патча в ядро, чтобы какие-то
> переключения групп работали с привилегиями, не эквивалентными root'у. Таким образом, мы
> получили бы либо недоделку, либо неоправданно сложную (и поэтому опасную) конструкцию.
> И всё ради возможности о которой мало кто знает и совсем
> мало кто пользуется. К этому можно добавить еще и принципиальные риски,
> связанные с использованием newgrp из-под пользователя. Поэтому мы поступили проще и
> поставляем gpasswd и newgrp доступными только root'у, и control-файлы для тех
> немногих, кто хочет эту возможность включить (на свой риск).
> Так что нет, мы считаем tcb доделанным.
> Если проектом снова заняться всерьез, надо бы переписать скрипты на iproute2.Это уже сделано в etcnet, если что.
> ........В дистрибутиве по умолчанию применяются передовые методы обеспечения защиты........Интересует также результат прохождение передовых тестов:
paxtest http://pax.grsecurity.net/
checksec http://tk-blog.blogspot.ru/search/label/checksec.sh
hardening-check https://wiki.debian.org/Hardening
>> ........В дистрибутиве по умолчанию применяются передовые методы обеспечения защиты........... но далеко не все. По ряду показателей Owl сейчас отстает от других hardened дистрибутивов Linux, но и те, в свою очередь отстают от Owl по другим показателям. Я недавно упомянул это здесь - http://www.openwall.com/lists/owl-users/2014/12/30/1
"Finally, as to the future of Owl itself, we need to know why we'd be
continuing to put effort into Owl. Do we have more new approaches to
demo to others in this way, or would we be playing catch-up? I think it
might be mostly the latter. There are things other hardened distros did
and we didn't do yet, so we can merge those in and create a distro that
is in some ways better overall. (In fact, this was the plan a couple of
years ago, but we didn't proceed to execute on it much yet.) However,
we would not demo much new in this way, except for the combination of
what we already had and what others already had, and along with newer
upstream software versions. Is demo'ing this combination worth the
effort? Would it inspire others to do anything better? Is it worth the
effort merely for actual use of it during the period that we'd be
maintaining it and keeping it up-to-date?"> Интересует также результат прохождение передовых тестов:
> paxtest http://pax.grsecurity.net/
> checksec http://tk-blog.blogspot.ru/search/label/checksec.sh
> hardening-check https://wiki.debian.org/Hardening
> scanelf http://hardened.gentoo.org/pax-utils.xmlЭти тесты направлены на hardening от memory corruption атак. Это область которой в том числе и я занимался до начала проекта Owl. В Owl же мы изначально сделали упор на переделку userland'а, в частности для privilege separation, в чем и достигли успехов, но при этом мы уже почти не занимались дальнейшим hardening'ом от memory corruption атак. Появившиеся за эти годы другие hardened-дистрибутивы достигли успехов в той области. Теперь вопрос - стоит ли нам потратить еще время и объединить лучшие наработки? И в рамках какого проекта (или каких проектов)?
По paxtest результаты должны быть аналогичны RHEL 5.11 на соответствующих архитектурах - т.е. до PaX'а далеко, но и не совсем ужасно. Кому не нужна поддержка OpenVZ, могут использовать наш userland с ядром grsecurity и получить соответствующие ему результаты этого теста. По checksec, типичный бинарник из нашей сборки сейчас покажет Full RELRO и NX enabled, но пока что No canary found и No PIE - это собираемся поправить.
PAX & Grsecurity занимаются почти исключительно ядром Linux и компилятором GCC. Пока утверждают и доказывают, что этого хватает для закрытия всех возможных уязвимостей, или препятствию развития атаки! Когда другие спешно обновляются, чтобы закрыть одну дыру, или пишут антивирусник защищающий дыру, то https://grsecurity.net/ внедряют в ядро Linux технологию которая закрывает сразу от всего подобного класса атак и делает невозможным эксплуатацию всех подобных (ещё публично неизвестных) дыр.> ....В Owl же мы изначально сделали упор на переделку userland'а, в частности для privilege separation, в чем и достигли успехов....
Сравнительная таблица grsecurity, selinux, apparmor: https://grsecurity.net/compare.php интересно было увидеть также Owl..
для разграничения привилегий в пользовательском окружении используются разные техники:
1. приямые и явные политики на основе списков доступа до косвенных
2. неявные - рандомизация памяти (PAX), адресов линковки (PIE), списка процессов (скрытие proc), ... и предоставление процессу только необходимой и достаточной информации. Если процесс не угадал с адресом или ещё чем, то его ядро убивает.> Теперь вопрос - стоит ли нам потратить еще время и объединить лучшие наработки? И в рамках какого проекта (или каких проектов)?
Не готов дать совет:(
В мире линукс выбор между
Hardened Gentoo https://wiki.gentoo.org/wiki/Project:Hardened
Hardened Debian https://wiki.debian.org/Hardening
последний мертвый, может в https://devuan.org/ пойдут дела быстрее...Если у вас переделан сильно юзерленд, то лучше наверно общатся с разрабами конкретных прог... слать им падчи и обяснять им необходимость усиления privilege separation. Но по моему печальному опыту проще уболтать разрабов процов добавить ещё инструкцию для ускорение обработки каких-то систем безопасности чем закомитить патчи в апстрим.
> PAX & Grsecurity занимаются почти исключительно ядром Linux и компилятором GCC.Я в курсе. Довольно странно мне рассказывать про проект, который исходно появился как порт моего же патча, на тот момент с ядра 2.2.x на 2.4.x. Разве что если бы я совсем не следил за его дальнейшим развитием. Но я всё же слегка поглядываю и немного общаюсь. Я частично потому и забросил эту область сам, что ей занялись другие.
> Сравнительная таблица grsecurity, selinux, apparmor: https://grsecurity.net/compare.php
> интересно было увидеть также Owl..Owl плохо для такого сравнения подходит. Даже сравнение с SELinux и AppArmor довольно странное. Да, в grsecurity тоже есть средства mandatory access control, но, думаю, их мало кто использует. Возможно, они там даже не к месту.
> для разграничения привилегий в пользовательском окружении используются разные техники:
Это не privilege separation. Это privilege reduction и hardening.
> Если у вас переделан сильно юзерленд, то лучше наверно общатся с разрабами
> конкретных прог... слать им падчи и обяснять им необходимость усиления privilege
> separation. Но по моему печальному опыту проще уболтать разрабов процов добавить
> ещё инструкцию для ускорение обработки каких-то систем безопасности чем закомитить патчи
> в апстрим.Странный опыт. Продвинуть что-либо в upstream действительно бывает непросто, но сравнение надуманное. Некоторые наши патчи вошли в разные upstream'ы. Из относящихся к безопасности, упомянутая здесь поддержка non-raw ICMP sockets вошла в upstream ядро (откуда ее, кстати, еще и бек-портировали в RHEL6, так что наш не-SUID'ный ping работает на RHEL6/CentOS 6 - мы этим пользуемся когда слегка harden'им такие системы у клиентов).
P.S. Вижу кто-то "минуснул" ваш комментарий. Не я. Я просто общаюсь.
> Довольно странно мне рассказывать про проект, который исходно появился как порт моего же патча, на тот момент с ядра 2.2.x на 2.4.x.Респект!
> Да, в grsecurity тоже есть средства mandatory access control, но, думаю, их мало кто использует. Возможно, они там даже не к месту.
gradm умеет автоматом создавать политики! в сравнении с selinux где политики надо писать выиграш есть. Кроме того разработка АНБ selinux отталкивает.
> Из относящихся к безопасности, упомянутая здесь поддержка non-raw ICMP sockets вошла в upstream ядро (откуда ее, кстати, еще и бек-портировали в RHEL6, так что наш не-SUID'ный ping работает...
Обязательно попробую. Пока скрипты с fping от рута пускаю.. но в будущем постараюсь использовать ваши патчи.
>P.S. Вижу кто-то "минуснул" ваш комментарий. Не я. Я просто общаюсь.
на такое не обращаю внимания.
> И в рамках какого проекта (или каких проектов)?Свяжись с gentoo-hardened на lists.gentoo.org или #gentoo-hardened на irc.freenode.net если дадут добро то интеграция займёт мало времени:
1. разбитие ваших наработок по юзерленду на отдельные патчи к конкретным пакетам, или дополнительные пакеты.
2. добавление в portage ещё одного флага USE owl
3. копирование патчей в соотведствующие пакеты и правка ebuild файлов этих пакетов, чтобы при выборе пользователем флага owl накладывались патчи и проводились другие необходимые действия..
>> И в рамках какого проекта (или каких проектов)?
> Свяжись с gentoo-hardened на lists.gentoo.org или #gentoo-hardened на irc.freenode.netМы немного общаемся с конкретными ребятами "из Gentoo", но активно туда что-то продвигать пока не пробовали. Не будучи хотя бы пользователем Gentoo, я не стану сам что-то туда продвигать (разве что могу помочь советом, если этим кто-то займется). Но если кто-то из нашей команды станет - я только за.
> если дадут добро то интеграция займёт мало времени:
> 1. разбитие ваших наработок по юзерленду на отдельные патчи к конкретным пакетам,
> или дополнительные пакеты.Наши наработки и так в таком виде. Скорее работа потребуется по портированию на другие (скорее всего, более новые) upstream-версии.
> 2. добавление в portage ещё одного флага USE owl
> 3. копирование патчей в соотведствующие пакеты и правка ebuild файлов этих пакетов,
> чтобы при выборе пользователем флага owl накладывались патчи и проводились другие
> необходимые действия..Думаю, большинство патчей должно применяться без всякого флага.
Пока что есть неофициальная инструкция по интеграции нашего tcb в Gentoo:
http://www.openwall.com/tcb/
http://felinemenace.org/~andrewg/configuring_gentoo_to_use_o.../(правда, что-то сейчас этот URL не отвечает).
> Мы немного общаемся с конкретными ребятами "из Gentoo", но активно туда что-то
> продвигать пока не пробовали. Не будучи хотя бы пользователем Gentoo, я
> не стану сам что-то туда продвигать (разве что могу помочь советом,
> если этим кто-то займется). Но если кто-то из нашей команды станет
> - я только за.При других обстоятельствах может бы взялся за поддержку ваших патчей в Гентоо, но сей час мне не до этого.
> Наши наработки и так в таком виде. Скорее работа потребуется по портированию
> на другие (скорее всего, более новые) upstream-версии.Лучше продвигать в апстрим, так ваши наработки сразу появятся у всех дистрибутивах! Ребята "из Gentoo" часто общаются с разрабами о продвижении патчей в апстримы, возможно помогут.
> Лучше продвигать в апстримДля очевидных фиксов так и делаем. С требующими обсуждения/убеждения вещами - сложнее.
> Ребята "из Gentoo" часто общаются с разрабами о продвижении патчей в
> апстримы, возможно помогут.Gentoo нам уже немного помогли передав один из слотов в GSoC 2011 (от их организации - нашей) для продвижения hardening-патчей в mainstream ядро, что мы тогда немного и поделали: http://lwn.net/Articles/451405/
А "общаться с разрабами" всё же лучше непосредственно авторам предлагаемых изменений.
> http://lwn.net/Articles/451405/Хотел задать ещё вопрос о ситуации с продвижением патчей grsecurity/PaX и Openwall в ядро, положение дел понял но не совсем ;)
Есть патчи которые блягодаря современным процам абсолютно не влияют на производительность, также не добавляют видимой сложности поддержки кода. Мотивацию в отказе найти сложно, от АНБ selinux принимается, ваши наработки нет...
> Хотел задать ещё вопрос о ситуации с продвижением патчей grsecurity/PaX и Openwall
> в ядро, положение дел понял но не совсем ;)Я когда-то частично это прокомментировал здесь: http://www.opennet.me/openforum/vsluhforumID3/70592.html#14
> Есть патчи которые блягодаря современным процам абсолютно не влияют на производительность,
> также не добавляют видимой сложности поддержки кода. Мотивацию в отказе найти
> сложноЧасто бывают не то чтобы принципиальные отказы, а недовольство выбранным подходом и/или особенностями реализации. За несколько попыток, с переделками, отдельные вещи продвинуть можно. Если сразу не удается, то через год-другой можно тему поднимать повторно и пробовать еще раз - мнения upstream'а меняются. Но мало кто готов этим заниматься. И да, не 100% изменений (даже переделанных) таким образом примут, но, по моему мнению, могут принять еще многое. Разработчики grsecurity, как я понимаю, другого мнения - что-то вроде "пока такой-то, который говорил такие-то глупости, в том числе и недавно, участвует в принятии решений, пытаться что-то продвигать в ядро немного глупо и для нас унизительно, да мы и не хотим" (это моя интерпретация кучи отдельных твитов и комментариев, возможно я ошибаюсь). И дело тут не в одном "таком-то", конечно. Они на его высказывания ссылаются для примера. Но я вижу эту ситуацию не так черно-бело, как они.
> от АНБ selinux принимается, ваши наработки нет...
Кое-что принималось. Лично я и не пытался продвигать hardening-патчи при этом следуя всем правилам, так что мне не на что жаловаться. Когда мы пробовали продвигать патчи по правилам в рамках GSoC 2011 (фактически я, как ментор, поручил эту неблагодарную работу Василию), результат был умеренно положительным.