The OpenNET Project / Index page

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

Анонсирован Openwall GNU/*/Linux 3.1-stable

05.01.2015 10:01

Спустя 4 года с момента прошлого значительного выпуска представлена новая стабильная ветка Openwall GNU/*/Linux (Owl) 3.1-stable, компактного дистрибутива GNU/Linux для серверов и виртуализированных окружений, ориентированного на обеспечение высокой безопасности. Owl 3.1-stable теперь будет поддерживаться в качестве стабильной ветки, а дальнейшая разработка продолжится в ветке Owl-current. Поддержка ветки Owl 3.0-stable официально прекращена. Так как в ветке 3.1-stable представлены некоторые важные обновления, в том числе устранение уязвимости CVE-2014-9322, пользователям рекомендуется выполнить обновление до новой ветки. Доступны ISO-образы (560Мб) с Live-системой и инсталлятором, которые подготовлены для архитектур i686 и x86-64. Также доступен шаблон для компоновки базовой системы контейнеров OpenVZ.

Owl может использоваться как для создания высокозащищённых серверных систем, так и для создания базовой начинки изолированных контейнеров и организации работы контейнерной виртуализации на основе OpenVZ. В дистрибутиве по умолчанию применяются передовые методы обеспечения защиты, используются наиболее безопасные настройки (например, по умолчанию не поставляется программ с флагом suid) и поставляются только пакеты, заслуживающие доверия и прошедшие аудит исходного кода. Кроме готовых бинарных пакетов, предоставляются удобные средства для пересборки пакетов из исходных текстов (make buildworld) и формирования iso-образа или начинки виртуального окружения.

В новой ветке:

  • Осуществлён переход на ядро 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.
  • Добавлены пакеты: 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.0o, 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.


  1. Главная ссылка к новости (http://www.openwall.com/lists/...)
  2. OpenNews: HPC Village от Openwall: доступ к гибридной HPC-системе для Open Source разработчиков
  3. OpenNews: Проект Openwall представил web-интерфейс blists и новый список рассылки kernel-hardening
  4. OpenNews: Вышел Openwall GNU/*/Linux 3.0. Проекту 10 лет
  5. OpenNews: Обновлены патчи ядра Linux от Openwall и подготовлены установочные образы дистрибутива Owl
  6. OpenNews: В проект Owl добавлена поддержка OpenVZ и осуществлен переход на Linux ядро 2.6.x
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/41394-openwall
Ключевые слова: openwall, owl
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (68) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 11:25, 05/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    При сборке пакетов по умолчанию включены опции "-Wl,-z,relro" и "-Wl,-z"
    "эпический вин" и как относится к безопасности не ясно.
     
     
  • 2.11, Аноним (-), 13:54, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тут все расписано https://wiki.debian.org/Hardening
     
  • 2.31, Аноним (-), 18:32, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > "эпический вин" и как относится к безопасности не ясно.

    А ты попробуй hardening-check /your/executable - узнаешь для себя много нового.

     
  • 2.35, Аноним (-), 20:10, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > и "-Wl,-z"

    :facepalm:

     

  • 1.2, Аноним (-), 11:42, 05/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    штабильность! ©

    > Осуществлён переход на ядро Linux 2.6.18

     
     
  • 2.41, Michael Shigorin (ok), 01:33, 06/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > штабильность! ©
    >> Осуществлён переход на ядро Linux 2.6.18

    С предыдущего, которое тоже "2.6.18" и тоже разве что по надписи на борту.  Вы вообще читаете перед тем, как писать?..

     

  • 1.3, Baz (?), 12:03, 05/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    это уже не просто консерватизм, а диагноз...
     
     
  • 2.4, Andrey Mitrofanov (?), 12:13, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >а диагноз...

    Конечно! Твой рогрессивизм же не межет быть диагнозом. Конечно, нет-нет!!

     
  • 2.27, Аноним (-), 18:04, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >  это уже не просто консерватизм, а диагноз...

    Ну так давно известно что самая безопасная система - та которой никто не пользуется. Для надежности желательно чтобы она еще и не загружалась. На случай если кто-то вдруг додумается попробовать включить компьютер.

     

  • 1.5, Сергей (??), 12:20, 05/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Как это сочетать
    ориентированного на обеспечение высокой безопасности и Вместо /bin/sh для интерактивного сеанса задействован /bin/bash...
     
     
  • 2.9, Аноним (-), 13:17, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    всё просто: фраза "Owl может использоваться как для создания высокозащищённых серверных систем, ..." не говорит, каким именно образом он должен использоваться.
    Возможно, диск с дистрибутивом надо подкладывать куда-то под серверную стойку...
     
  • 2.15, solardiz (ok), 15:21, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Вместо /bin/sh для интерактивного сеанса задействован /bin/bash...

    Я сначала даже не понял откуда это взялось, но потом нашел у нас в CHANGES-3.1 запись, которая могла быть так интерпретирована. На самом деле, в ней речь шла об изменении имени шелла (а не самого шелла) при работе с LiveCD, чтобы включалась цветная выдача в команде ls. А bash запускался и до и после этого изменения. В качестве альтернативы в Owl есть tcsh. Иронию насчет bash'а и его излишней функциональности я понимаю и принимаю:

    http://www.openwall.com/presentations/ZeroNights2014-Is-Infosec-A-Game/slide-
    http://www.openwall.com/presentations/ZeroNights2014-Is-Infosec-A-Game/slide-

    Разумеется, Shellshock в Owl 3.1-stable исправлен. Но ирония осталась, да и раньше была.

     
     
  • 3.21, EHLO (?), 16:18, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > нас в CHANGES-3.1 запись, которая могла быть так интерпретирована. На самом
    > деле, в ней речь шла об изменении имени шелла (а не
    > самого шелла) при работе с LiveCD, чтобы включалась цветная выдача в
    > команде ls. А bash запускался и до и после этого изменения.
    > В качестве альтернативы в Owl есть tcsh. Иронию насчет bash'а и
    > его излишней функциональности я понимаю и принимаю:
    > http://www.openwall.com/presentations/ZeroNights2014-Is-Infosec-A-Game/slide-
    > http://www.openwall.com/presentations/ZeroNights2014-Is-Infosec-A-Game/slide-
    > Разумеется, Shellshock в Owl 3.1-stable исправлен. Но ирония осталась, да и раньше
    > была.

    То есть переход на что-то полегче в /bin/sh и bash как login shell как в Дебиане не планируете?

     
     
  • 4.24, solardiz (ok), 17:40, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > То есть переход на что-то полегче в /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 должна быть), но в отдельном случае можно и ошибиться. Не хотелось бы принимать решения не изучив вопрос всерьез, но и не хотелось бы тратить значительное время на не очень важный для проекта вопрос. (Да, у меня опять вышел слишком длинный ответ.)

     
     
  • 5.28, Аноним (-), 18:14, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А это потому что все это скриптовое болото писаное левой пяткой никто не пробова... большой текст свёрнут, показать
     
     
  • 6.32, solardiz (ok), 18:50, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >> Shellshock - это (пока?) один такой пример за ~25 лет.
    > А это потому что все это скриптовое болото писаное левой пяткой никто не пробовал палочкой тыкать

    Да нет, в скриптах уязвимости то и дело находят. И в bash, так скажем, особенности бывали, хотя и на удивление мало (известных) - лет 15 назад была история с обработкой символа '\xff' в скриптах. Но Shellshock выделяется тем, что обрабатывались произвольные переменные окружения, bash'у и конкретным скриптам не предназначенные, в результате чего уязвимым оказался запуск бинарных программ через "bash -c", system(), popen() и т.д. даже при отсутствии скриптов (в полном смысле).

     
     
  • 7.47, Аноним (-), 12:58, 06/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Да нет, в скриптах уязвимости то и дело находят.

    И почему я не удивлен? :)

    А шеллшок выделяется тем что показал что
    1) Нефиг пихать стремные фичи "чтоб было". Идея как-то сильно кастомно обрабатывать переменные окружения - это по любому хорошая заявка на залет.
    2) Это же касается и иных входных данных. В шелскриптах вечный гемор с эскейпингом и специальной обработкой кучи всего. Если скриптам отдавать хоть какие-то данные, приезжающие с недоверяемых внешних систем - там целое поле для грабель. А скриптеры к тому же очень редко думают о таком развитии ситуации.

     

  • 1.6, commiethebeastie (ok), 12:49, 05/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Число создаваемых устройств /dev/sd* увеличено с 8 до 16.
    >vconfig
    >Linux 2.6.18-400.el5.028stab117.2

    Ностальжи.

     
  • 1.7, pipip (?), 12:56, 05/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Десктоп параноика
     
     
  • 2.16, Аноним (-), 15:38, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • –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]#
     
     
  • 3.22, MIRV (?), 16:33, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Батенька в винде любит посидеть? :)
     
     
  • 4.34, Аноним (-), 19:49, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Только поиграть :)
     
  • 2.29, Аноним (-), 18:16, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Десктоп параноика

    Десктоп с ядром 2.6.18? Ну... если запускать это на той же машине что жидитоба реактос - тогда наверное нормально.

     

  • 1.8, dmnord (ok), 13:02, 05/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    старовато ядрышко, безопасность видимо на самом первом плане!
     
     
  • 2.10, Аноним (-), 13:18, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Новые эксплойты делаются под современный софт и новые ядра.
    Очень оригинальный защитный ход.
     
     
  • 3.17, Аноним (-), 15:39, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Новые эксплойты делаются под современный софт и новые ядра.
    > Очень оригинальный защитный ход.

    Понабежали школьники, не знающие про RHEL.

     
     
  • 4.30, Аноним (-), 18:16, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Понабежали школьники, не знающие про RHEL.

    Так нынче рхел 7 уж вышел. А это из пятого еще...

     
  • 3.46, Аноним (-), 11:00, 06/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >Новые эксплойты делаются под современный софт и новые ядра.

    Очень оригинальный защитный ход.
    Security by obscurity?

     
  • 2.19, solardiz (ok), 16:02, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Старовато, да. Особенно учитывая предстоящий в феврале 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, какую ветку/версию ядра мы бы ни выбрали.

    Тут кто-то упомянул наличие/отсутствие эксплойтов под разные ядра. Уточню: выше я говорю именно про сами уязвимости (и их наличие или отсутствие), а не про эксплойты.

     

  • 1.12, Аноним (-), 13:56, 05/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    От платных эксплойтов вас и старое ядро не спасет....
     
  • 1.14, solardiz (ok), 15:01, 05/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    На самом деле мы (разработчики) не считаем выход 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

     
     
  • 2.18, Аноним (-), 15:41, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Это действительно хорошая новость. Также, как и JTR jumbo. Последнего заждались, да)
     
  • 2.20, анон (?), 16:07, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    solardiz, новости о jtr из первых рук были бы интересны. Для людей не подписанных на рассылки (я отписался пару лет тому назад), но желающих быть в курсе в общих чертах о происходящем было бы удобно. Я бы хотел видеть эти новости на opennet. Так что, если не тяжело, хотя бы пару строк в mini-новости не плохо бывало бы тиснуть касательно новых jambo.

    C уважением за труды.

     
     
  • 3.26, solardiz (ok), 17:52, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > solardiz, новости о jtr из первых рук были бы интересны. Для людей
    > не подписанных на рассылки (я отписался пару лет тому назад), но
    > желающих быть в курсе в общих чертах о происходящем было бы
    > удобно. Я бы хотел видеть эти новости на opennet. Так что,
    > если не тяжело, хотя бы пару строк в mini-новости не плохо
    > бывало бы тиснуть касательно новых jambo.

    Не тяжело, но я всё же не стану каждое обновление jumbo анонсировать здесь. Это было бы спамом, учитывая что разных открытых проектов много. Советую подписаться на наш список announce - там очень низкий трафик - гораздо ниже, чем в john-users и john-dev. За почти 15 лет существования списка - всего 199 сообщений. Это примерно одно в месяц.

    http://www.openwall.com/lists/announce/

    Думаю, это как раз то, что нужно, чтобы "быть в курсе в общих чертах о происходящем". А наши новости на OpenNet раз в месяц - это было бы слишком часто.

     
  • 2.33, myhand (ok), 19:08, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Конечно.  Ключевое слово systemd - отсутствует же.
     
  • 2.42, Michael Shigorin (ok), 01:54, 06/01/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > На самом деле мы (разработчики) не считаем выход 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.dev/opennews/art.shtml?num=39050 и нашлось http://comments.gmane.org/gmane.linux.openwall.devel/467 (2012).

     
     
  • 3.44, solardiz (ok), 09:08, 06/01/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > ...или даже следует :-)

    Здесь есть какие-то "правила" о (не) публикации "старых новостей"? Пока что я видел здесь "старые новости" в случаях, когда тему снова подняли и активно обсуждают где-то еще (например, так было с новостью о проблемах с 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.

     
     
  • 4.52, Michael Shigorin (ok), 18:15, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > На данный момент, я вижу интеграцию systemd в первую очередь как способ
    > растерять/"прогнать" часть сообщества, что, конечно, является аргументом
    > против systemd.

    А какие приводятся технические аргументы?  На localhost systemd нет в силу характерных методов его "продвижения" (и для меня этого достаточно даже без увеличения поверхности атаки "низов" системы), но интересно, как у коллег.

    PS: с Рождеством!

     
     
  • 5.54, solardiz (ok), 14:05, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А какие приводятся технические аргументы?

    Все, приведенные именно в контексте разработки Owl, есть в том треде в owl-users. Я лучше не стану пытаться их пересказать. В целом, вопрос сводится к тому насколько далеко или близко к mainstream'у Owl должен быть. По-моему, начиная с какой-то степени приближенности к mainstream'у Owl теряет смысл как самостоятельный проект. Но никто точно не скажет где именно проходит эта грань.

    Кстати, взяв Linux, а не что-то изначально лучшее для безопасности с точки зрения архитектуры и/или объема кода, мы уже в какой-то степени пошли на поводу у mainstream'а. На тот момент (1999-2000 год) это было связано с тем, что эта ниша выглядела свободной и нуждающейся в новом проекте. Думаю, подобные рассуждения (но, возможно, с другими выводами) могут быть применены и сейчас, для принятия решений о будущем проекта.

     
     
  • 6.55, Michael Shigorin (ok), 16:29, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> А какие приводятся технические аргументы?
    > Все, приведенные именно в контексте разработки 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 -- включаем подсистему"; возможно, и Вам либо коллегам покажется интересным.

     
     
  • 7.59, solardiz (ok), 11:26, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>> А какие приводятся технические аргументы?
    >> Все, приведенные именно в контексте разработки Owl, есть в том треде в owl-users.
    > В этом? -- http://www.openwall.com/lists/owl-users/2014/12/21/2

    Да, в этом треде (в сообщениях от galaxy@).

     
  • 2.53, Аноним (-), 18:31, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Но о нем здесь новости не было. Возможно, мне следовало ее
    > запостить.)

    Было бы неимоверно круто если бы вы это делали. Я иногда посматриваю на него, но сильно реже чем следовало бы. А хорошая софтина.

    Заодно можно наверное было бы потестить оным на глючность опенсорсный вычислительный стек. Поблевать^W наколотить баги в багтрекер и посмотреть кто, сколько и где выжимает :).

     

  • 1.23, Аноним (-), 17:40, 05/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >Добавлена утилита PV ("Pipe Viewer") для >наглядной оценки прогресса передачи >данных через неименованный канал;

    Какие данные передаются через пипец, например?

     
     
  • 2.43, Michael Shigorin (ok), 01:57, 06/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >>Добавлена утилита PV ("Pipe Viewer") для
    >>наглядной оценки прогресса передачи
    >>данных через неименованный канал;
    > Какие данные передаются через пипец, например?

    Например, удобно с длинным dd(1) заместо размахивания сигналами и прикидки в уме.

     

  • 1.36, Амоним (?), 20:27, 05/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А systemd будет?
     
     
  • 2.37, Аноним (-), 20:57, 05/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Всенепременно. C ядром 2.6.18, да.
     
  • 2.70, Аноним (-), 12:26, 13/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > А systemd будет?

    ненужно

     

  • 1.38, Amnesiac (?), 22:11, 05/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    не понял, а зачем этот древний vconfig?
    разве "ip link add link eth0 name eth0.123 type vlan id 123" не торт?
     
     
  • 2.40, Аноним (-), 01:12, 06/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    vconfig add eth0 123
     
     
  • 3.48, Amnesiac (?), 17:35, 06/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    И что? Типа, короче? Тю!

    # 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

     
  • 2.45, solardiz (ok), 09:18, 06/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > не понял, а зачем этот древний vconfig?

    Legacy. По сути уже не нужен. Если проектом снова заняться всерьез, надо бы переписать скрипты на iproute2.

     
     
  • 3.49, Павел Самсонов (?), 11:48, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Я смотрел ранее openwall, и как это ни странно меня больше всего заинтересовало переведение shadow на tcb, но решение какое то не полное, сделано только для shadow, а для passwd group gshadow нет. У вас собираются это доделывать?
     
     
  • 4.50, solardiz (ok), 12:24, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    nitpick JFYI, Openwall - это наша команда У нас несколько своих проектов, а т... большой текст свёрнут, показать
     
     
  • 5.56, Павел Самсонов (?), 18:18, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > Не странно. Это один из компонентов, требовавшихся для ухода от 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 доделанным.

    Если у меня будут силы и время может я форкну вашу либку :-)


     
     
  • 6.58, solardiz (ok), 11:23, 09/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > для смены 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-against-file-systems
    http://2013.zeronights.org/includes/docs/Ivan_Novikov_-_Filesystem_timing_att

     
  • 5.57, Павел Самсонов (?), 18:38, 08/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > файлов "для красоты"? Нет, для безопасности это не нужно. Аналогично с
    > 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 доделанным.

     
  • 3.51, Michael Shigorin (ok), 18:12, 07/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Если проектом снова заняться всерьез, надо бы переписать скрипты на iproute2.

    Это уже сделано в etcnet, если что.

     

  • 1.60, Аноним (-), 17:55, 10/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > ........В дистрибутиве по умолчанию применяются передовые методы обеспечения защиты........

    Интересует также результат прохождение передовых тестов:

    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

     
     
  • 2.61, solardiz (ok), 19:07, 10/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    но далеко не все По ряду показателей Owl сейчас отстает от других hardened ... большой текст свёрнут, показать
     
     
  • 3.63, Аноним (-), 16:58, 12/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    PAX Grsecurity занимаются почти исключительно ядром Linux и компилятором GCC ... большой текст свёрнут, показать
     
     
  • 4.65, solardiz (ok), 19:01, 12/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > 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. Вижу кто-то "минуснул" ваш комментарий. Не я. Я просто общаюсь.

     
     
  • 5.67, Аноним (-), 10:51, 13/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Респект gradm умеет автоматом создавать политики в сравнении с selinux где пол... большой текст свёрнут, показать
     
  • 3.64, Аноним (-), 17:18, 12/01/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И в рамках какого проекта (или каких проектов)?

    Свяжись с gentoo-hardened на lists.gentoo.org или #gentoo-hardened на irc.freenode.net если дадут добро то интеграция займёт мало времени:
    1. разбитие ваших наработок по юзерленду на отдельные патчи к конкретным пакетам, или дополнительные пакеты.
    2. добавление в portage ещё одного флага USE owl
    3. копирование патчей в соотведствующие пакеты и правка ebuild файлов этих пакетов, чтобы при выборе пользователем флага owl накладывались патчи и проводились другие необходимые действия..

     
     
  • 4.66, solardiz (ok), 19:12, 12/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> И в рамках какого проекта (или каких проектов)?
    > Свяжись с 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_openwall_tcb/

    (правда, что-то сейчас этот URL не отвечает).

     
     
  • 5.68, Аноним (-), 11:02, 13/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Мы немного общаемся с конкретными ребятами "из Gentoo", но активно туда что-то
    > продвигать пока не пробовали. Не будучи хотя бы пользователем Gentoo, я
    > не стану сам что-то туда продвигать (разве что могу помочь советом,
    > если этим кто-то займется). Но если кто-то из нашей команды станет
    > - я только за.

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

    > Наши наработки и так в таком виде. Скорее работа потребуется по портированию
    > на другие (скорее всего, более новые) upstream-версии.

    Лучше продвигать в апстрим, так ваши наработки сразу появятся у всех дистрибутивах! Ребята "из Gentoo" часто общаются с разрабами о продвижении патчей в апстримы, возможно помогут.

     
     
  • 6.69, solardiz (ok), 11:20, 13/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Лучше продвигать в апстрим

    Для очевидных фиксов так и делаем. С требующими обсуждения/убеждения вещами - сложнее.

    > Ребята "из Gentoo" часто общаются с разрабами о продвижении патчей в
    > апстримы, возможно помогут.

    Gentoo нам уже немного помогли передав один из слотов в GSoC 2011 (от их организации - нашей) для продвижения hardening-патчей в mainstream ядро, что мы тогда немного и поделали: http://lwn.net/Articles/451405/

    А "общаться с разрабами" всё же лучше непосредственно авторам предлагаемых изменений.

     
     
  • 7.71, Аноним (-), 13:05, 13/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > http://lwn.net/Articles/451405/

    Хотел задать ещё вопрос о ситуации с продвижением патчей grsecurity/PaX и Openwall в ядро, положение дел понял но не совсем ;)

    Есть патчи которые блягодаря современным процам абсолютно не влияют на производительность, также не добавляют видимой сложности поддержки кода. Мотивацию в отказе найти сложно, от АНБ selinux принимается, ваши наработки нет...

     
     
  • 8.72, solardiz (ok), 17:35, 13/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Я когда-то частично это прокомментировал здесь http www opennet ru openforum ... текст свёрнут, показать
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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