форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
Сообщение от opennews (??) on 05-Янв-15, 11:25
Спустя 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
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	–3 +/–
Сообщение от Аноним (??) on 05-Янв-15, 11:25
При сборке пакетов по умолчанию включены опции "-Wl,-z,relro" и "-Wl,-z" "эпический вин" и как относится к безопасности не ясно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+1 +/–
	Сообщение от Аноним (??) on 05-Янв-15, 13:54
	Тут все расписано https://wiki.debian.org/Hardening
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	31. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+1 +/–
	Сообщение от Аноним (??) on 05-Янв-15, 18:32
	> "эпический вин" и как относится к безопасности не ясно. А ты попробуй hardening-check /your/executable - узнаешь для себя много нового.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	35. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Аноним (??) on 05-Янв-15, 20:10
	> и "-Wl,-z" :facepalm:
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+3 +/–
Сообщение от Аноним (??) on 05-Янв-15, 11:42
штабильность! © > Осуществлён переход на ядро Linux 2.6.18
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	41. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Michael Shigorin (ok) on 06-Янв-15, 01:33
	> штабильность! © >> Осуществлён переход на ядро Linux 2.6.18 С предыдущего, которое тоже "2.6.18" и тоже разве что по надписи на борту.  Вы вообще читаете перед тем, как писать?..
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	–2 +/–
Сообщение от Baz on 05-Янв-15, 12:03
это уже не просто консерватизм, а диагноз...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+2 +/–
	Сообщение от Andrey Mitrofanov on 05-Янв-15, 12:13
	>а диагноз... Конечно! Твой рогрессивизм же не межет быть диагнозом. Конечно, нет-нет!!
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	27. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Аноним (??) on 05-Янв-15, 18:04
	>  это уже не просто консерватизм, а диагноз... Ну так давно известно что самая безопасная система - та которой никто не пользуется. Для надежности желательно чтобы она еще и не загружалась. На случай если кто-то вдруг додумается попробовать включить компьютер.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	–1 +/–
Сообщение от Сергей (??) on 05-Янв-15, 12:20
Как это сочетать ориентированного на обеспечение высокой безопасности и Вместо /bin/sh для интерактивного сеанса задействован /bin/bash...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Аноним (??) on 05-Янв-15, 13:17
	всё просто: фраза "Owl может использоваться как для создания высокозащищённых серверных систем, ..." не говорит, каким именно образом он должен использоваться. Возможно, диск с дистрибутивом надо подкладывать куда-то под серверную стойку...
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	15. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+4 +/–
	Сообщение от solardiz (ok) on 05-Янв-15, 15:21
	> Вместо /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 исправлен. Но ирония осталась, да и раньше была.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	21. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от EHLO on 05-Янв-15, 16:18
	>[оверквотинг удален] > нас в 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 как в Дебиане не планируете?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	24. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+1 +/–
	Сообщение от solardiz (ok) on 05-Янв-15, 17:40
	> То есть переход на что-то полегче в /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 должна быть), но в отдельном случае можно и ошибиться. Не хотелось бы принимать решения не изучив вопрос всерьез, но и не хотелось бы тратить значительное время на не очень важный для проекта вопрос. (Да, у меня опять вышел слишком длинный ответ.)
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	28. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Аноним (??) on 05-Янв-15, 18:14
	> Shellshock - это (пока?) один такой пример за ~25 лет. А это потому что все это скриптовое болото писаное левой пяткой никто не пробовал палочкой тыкать и это судя по всему была одна из первых попыток покормить скрипты работающих с внешними данными черти чем. Судя по результативности, когда на половине систем DHCP сервер может рута получить нахаляву - теперь внимания таким атакам будет больше. > Да, в bash много "лишнего", но для безопасности важен attack surface. Как по мне так куча скриптятины писаной без оглядки на интенсивную бомбардировку недоверяемыми данными, скомпонованными недружелюбно - похоже на целое отдельное минное поле. Большинство авторов скриптов при их написании элементарно не думает что вон те данные - приходят от ремотных систем и могут содержать что угодно. > А так ли уж больше attack surface в bash с полностью исправленным Shellshock Я бы сказал что в целом вываливание скриптятины писаной абы кем и абы как и потом кормление этого барахла внешними данными - выглядит как довольно стремное начинание. Вообще в целом. Шелл интерпретаторы весьма фичасты и сами по себе не создавались для работы с недоверяемыми входными данныи. А скрипты всегда были средством системной автоматизации. А не линией обороны. А тут всякие умники додумались через скрипты какие-нибудь параметры DHCP передавать. При том что туда DHCP может пхать что угодно. Я думаю что вас (и нас) будет ждать изрядно неприятных сюрпризов.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	32. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+3 +/–
	Сообщение от solardiz (ok) on 05-Янв-15, 18:50
	>> Shellshock - это (пока?) один такой пример за ~25 лет. > А это потому что все это скриптовое болото писаное левой пяткой никто не пробовал палочкой тыкать Да нет, в скриптах уязвимости то и дело находят. И в bash, так скажем, особенности бывали, хотя и на удивление мало (известных) - лет 15 назад была история с обработкой символа '\xff' в скриптах. Но Shellshock выделяется тем, что обрабатывались произвольные переменные окружения, bash'у и конкретным скриптам не предназначенные, в результате чего уязвимым оказался запуск бинарных программ через "bash -c", system(), popen() и т.д. даже при отсутствии скриптов (в полном смысле).
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	47. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Аноним (??) on 06-Янв-15, 12:58
	> Да нет, в скриптах уязвимости то и дело находят. И почему я не удивлен? :) А шеллшок выделяется тем что показал что 1) Нефиг пихать стремные фичи "чтоб было". Идея как-то сильно кастомно обрабатывать переменные окружения - это по любому хорошая заявка на залет. 2) Это же касается и иных входных данных. В шелскриптах вечный гемор с эскейпингом и специальной обработкой кучи всего. Если скриптам отдавать хоть какие-то данные, приезжающие с недоверяемых внешних систем - там целое поле для грабель. А скриптеры к тому же очень редко думают о таком развитии ситуации.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

6. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
Сообщение от commiethebeastie (ok) on 05-Янв-15, 12:49
>Число создаваемых устройств /dev/sd* увеличено с 8 до 16. >vconfig >Linux 2.6.18-400.el5.028stab117.2 Ностальжи.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
Сообщение от pipip on 05-Янв-15, 12:56
Десктоп параноика
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	–2 +/–
	Сообщение от Аноним (??) on 05-Янв-15, 15:38
	Десктоп параноика, батенька, это, например, 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]#
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	22. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+4 +/–
	Сообщение от MIRV on 05-Янв-15, 16:33
	Батенька в винде любит посидеть? :)
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	34. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Аноним (??) on 05-Янв-15, 19:49
	Только поиграть :)
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	29. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	–3 +/–
	Сообщение от Аноним (??) on 05-Янв-15, 18:16
	> Десктоп параноика Десктоп с ядром 2.6.18? Ну... если запускать это на той же машине что жидитоба реактос - тогда наверное нормально.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

8. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
Сообщение от dmnord (ok) on 05-Янв-15, 13:02
старовато ядрышко, безопасность видимо на самом первом плане!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Аноним (??) on 05-Янв-15, 13:18
	Новые эксплойты делаются под современный софт и новые ядра. Очень оригинальный защитный ход.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	17. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+4 +/–
	Сообщение от Аноним (??) on 05-Янв-15, 15:39
	> Новые эксплойты делаются под современный софт и новые ядра. > Очень оригинальный защитный ход. Понабежали школьники, не знающие про RHEL.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	30. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Аноним (??) on 05-Янв-15, 18:16
	> Понабежали школьники, не знающие про RHEL. Так нынче рхел 7 уж вышел. А это из пятого еще...
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	46. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Аноним (??) on 06-Янв-15, 11:00
	>Новые эксплойты делаются под современный софт и новые ядра. Очень оригинальный защитный ход. Security by obscurity?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	19. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+2 +/–
	Сообщение от solardiz (ok) on 05-Янв-15, 16:02
	Старовато, да. Особенно учитывая предстоящий в феврале 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, какую ветку/версию ядра мы бы ни выбрали. Тут кто-то упомянул наличие/отсутствие эксплойтов под разные ядра. Уточню: выше я говорю именно про сами уязвимости (и их наличие или отсутствие), а не про эксплойты.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

12. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	–1 +/–
Сообщение от Аноним (??) on 05-Янв-15, 13:56
От платных эксплойтов вас и старое ядро не спасет....
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+6 +/–
Сообщение от solardiz (ok) on 05-Янв-15, 15:01
На самом деле мы (разработчики) не считаем выход 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
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	18. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Аноним (??) on 05-Янв-15, 15:41
	Это действительно хорошая новость. Также, как и JTR jumbo. Последнего заждались, да)
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	20. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+1 +/–
	Сообщение от анон on 05-Янв-15, 16:07
	solardiz, новости о jtr из первых рук были бы интересны. Для людей не подписанных на рассылки (я отписался пару лет тому назад), но желающих быть в курсе в общих чертах о происходящем было бы удобно. Я бы хотел видеть эти новости на opennet. Так что, если не тяжело, хотя бы пару строк в mini-новости не плохо бывало бы тиснуть касательно новых jambo. C уважением за труды.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	26. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+1 +/–
	Сообщение от solardiz (ok) on 05-Янв-15, 17:52
	> solardiz, новости о jtr из первых рук были бы интересны. Для людей > не подписанных на рассылки (я отписался пару лет тому назад), но > желающих быть в курсе в общих чертах о происходящем было бы > удобно. Я бы хотел видеть эти новости на opennet. Так что, > если не тяжело, хотя бы пару строк в mini-новости не плохо > бывало бы тиснуть касательно новых jambo. Не тяжело, но я всё же не стану каждое обновление jumbo анонсировать здесь. Это было бы спамом, учитывая что разных открытых проектов много. Советую подписаться на наш список announce - там очень низкий трафик - гораздо ниже, чем в john-users и john-dev. За почти 15 лет существования списка - всего 199 сообщений. Это примерно одно в месяц. http://www.openwall.com/lists/announce/ Думаю, это как раз то, что нужно, чтобы "быть в курсе в общих чертах о происходящем". А наши новости на OpenNet раз в месяц - это было бы слишком часто.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	33. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	–1 +/–
	Сообщение от myhand (ok) on 05-Янв-15, 19:08
	Конечно.  Ключевое слово systemd - отсутствует же.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	42. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+2 +/–
	Сообщение от Michael Shigorin (ok) on 06-Янв-15, 01:54
	> На самом деле мы (разработчики) не считаем выход 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).
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	44. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+2 +/–
	Сообщение от solardiz (ok) on 06-Янв-15, 09:08
	> ...или даже следует :-) Здесь есть какие-то "правила" о (не) публикации "старых новостей"? Пока что я видел здесь "старые новости" в случаях, когда тему снова подняли и активно обсуждают где-то еще (например, так было с новостью о проблемах с 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.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	52. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Michael Shigorin (ok) on 07-Янв-15, 18:15
	> На данный момент, я вижу интеграцию systemd в первую очередь как способ > растерять/"прогнать" часть сообщества, что, конечно, является аргументом > против systemd. А какие приводятся технические аргументы?  На localhost systemd нет в силу характерных методов его "продвижения" (и для меня этого достаточно даже без увеличения поверхности атаки "низов" системы), но интересно, как у коллег. PS: с Рождеством!
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	54. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+1 +/–
	Сообщение от solardiz (ok) on 08-Янв-15, 14:05
	> А какие приводятся технические аргументы? Все, приведенные именно в контексте разработки Owl, есть в том треде в owl-users. Я лучше не стану пытаться их пересказать. В целом, вопрос сводится к тому насколько далеко или близко к mainstream'у Owl должен быть. По-моему, начиная с какой-то степени приближенности к mainstream'у Owl теряет смысл как самостоятельный проект. Но никто точно не скажет где именно проходит эта грань. Кстати, взяв Linux, а не что-то изначально лучшее для безопасности с точки зрения архитектуры и/или объема кода, мы уже в какой-то степени пошли на поводу у mainstream'а. На тот момент (1999-2000 год) это было связано с тем, что эта ниша выглядела свободной и нуждающейся в новом проекте. Думаю, подобные рассуждения (но, возможно, с другими выводами) могут быть применены и сейчас, для принятия решений о будущем проекта.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	55. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Michael Shigorin (ok) on 08-Янв-15, 16:29
	>> А какие приводятся технические аргументы? > Все, приведенные именно в контексте разработки 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 -- включаем подсистему"; возможно, и Вам либо коллегам покажется интересным.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	59. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+1 +/–
	Сообщение от solardiz (ok) on 09-Янв-15, 11:26
	>>> А какие приводятся технические аргументы? >> Все, приведенные именно в контексте разработки Owl, есть в том треде в owl-users. > В этом? -- http://www.openwall.com/lists/owl-users/2014/12/21/2 Да, в этом треде (в сообщениях от galaxy@).
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	53. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Аноним (??) on 07-Янв-15, 18:31
	> Но о нем здесь новости не было. Возможно, мне следовало ее > запостить.) Было бы неимоверно круто если бы вы это делали. Я иногда посматриваю на него, но сильно реже чем следовало бы. А хорошая софтина. Заодно можно наверное было бы потестить оным на глючность опенсорсный вычислительный стек. Поблевать^W наколотить баги в багтрекер и посмотреть кто, сколько и где выжимает :).
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

23. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	–1 +/–
Сообщение от Аноним (??) on 05-Янв-15, 17:40
>Добавлена утилита PV ("Pipe Viewer") для >наглядной оценки прогресса передачи >данных через неименованный канал; Какие данные передаются через пипец, например?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	43. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Michael Shigorin (ok) on 06-Янв-15, 01:57
	>>Добавлена утилита PV ("Pipe Viewer") для >>наглядной оценки прогресса передачи >>данных через неименованный канал; > Какие данные передаются через пипец, например? Например, удобно с длинным dd(1) заместо размахивания сигналами и прикидки в уме.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

36. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+1 +/–
Сообщение от Амоним on 05-Янв-15, 20:27
А systemd будет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	37. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Аноним (??) on 05-Янв-15, 20:57
	Всенепременно. C ядром 2.6.18, да.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	70. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Аноним (??) on 13-Янв-15, 12:26
	> А systemd будет? ненужно
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

38. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
Сообщение от Amnesiac on 05-Янв-15, 22:11
не понял, а зачем этот древний vconfig? разве "ip link add link eth0 name eth0.123 type vlan id 123" не торт?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	40. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+1 +/–
	Сообщение от Аноним (??) on 06-Янв-15, 01:12
	vconfig add eth0 123
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	48. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Amnesiac on 06-Янв-15, 17:35
	И что? Типа, короче? Тю! # 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
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	45. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+1 +/–
	Сообщение от solardiz (ok) on 06-Янв-15, 09:18
	> не понял, а зачем этот древний vconfig? Legacy. По сути уже не нужен. Если проектом снова заняться всерьез, надо бы переписать скрипты на iproute2.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	49. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Павел Самсонов on 07-Янв-15, 11:48
	Я смотрел ранее openwall, и как это ни странно меня больше всего заинтересовало переведение shadow на tcb, но решение какое то не полное, сделано только для shadow, а для passwd group gshadow нет. У вас собираются это доделывать?
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	50. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+2 +/–
	Сообщение от solardiz (ok) on 07-Янв-15, 12:24
	> Я смотрел ранее 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 доделанным.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	56. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Павел Самсонов on 08-Янв-15, 18:18
	>[оверквотинг удален] > Не странно. Это один из компонентов, требовавшихся для ухода от 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 доделанным. Если у меня будут силы и время может я форкну вашу либку :-)
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	58. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+1 +/–
	Сообщение от solardiz (ok) on 09-Янв-15, 11:23
	> для смены 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...
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	57. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Павел Самсонов on 08-Янв-15, 18:38
	>[оверквотинг удален] > файлов "для красоты"? Нет, для безопасности это не нужно. Аналогично с > 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 доделанным.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	51. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Michael Shigorin (ok) on 07-Янв-15, 18:12
	> Если проектом снова заняться всерьез, надо бы переписать скрипты на iproute2. Это уже сделано в etcnet, если что.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

60. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+1 +/–
Сообщение от Аноним (??) on 10-Янв-15, 17:55
> ........В дистрибутиве по умолчанию применяются передовые методы обеспечения защиты........ Интересует также результат прохождение передовых тестов: 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
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	61. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+1 +/–
	Сообщение от solardiz (ok) on 10-Янв-15, 19:07
	>> ........В дистрибутиве по умолчанию применяются передовые методы обеспечения защиты........ ... но далеко не все. По ряду показателей 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 - это собираемся поправить.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	63. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Аноним (??) on 12-Янв-15, 16:58
	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. Но по моему печальному опыту проще уболтать разрабов процов добавить ещё инструкцию для ускорение обработки каких-то систем безопасности чем закомитить патчи в апстрим.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	65. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+1 +/–
	Сообщение от solardiz (ok) on 12-Янв-15, 19:01
	> 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. Вижу кто-то "минуснул" ваш комментарий. Не я. Я просто общаюсь.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	67. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Аноним (??) on 13-Янв-15, 10:51
	> Довольно странно мне рассказывать про проект, который исходно появился как порт моего же патча, на тот момент с ядра 2.2.x на 2.4.x. Респект! > Да, в grsecurity тоже есть средства mandatory access control, но, думаю, их мало кто использует. Возможно, они там даже не к месту. gradm умеет автоматом создавать политики! в сравнении с selinux где политики надо писать выиграш есть. Кроме того разработка АНБ selinux отталкивает. > Из относящихся к безопасности, упомянутая здесь поддержка non-raw ICMP sockets вошла в upstream ядро (откуда ее, кстати, еще и бек-портировали в RHEL6, так что наш не-SUID'ный ping работает... Обязательно попробую. Пока скрипты с fping от рута пускаю.. но в будущем постараюсь использовать ваши патчи. >P.S. Вижу кто-то "минуснул" ваш комментарий. Не я. Я просто общаюсь. на такое не обращаю внимания.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	64. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+1 +/–
	Сообщение от Аноним (??) on 12-Янв-15, 17:18
	> И в рамках какого проекта (или каких проектов)? Свяжись с gentoo-hardened на lists.gentoo.org или #gentoo-hardened на irc.freenode.net если дадут добро то интеграция займёт мало времени: 1. разбитие ваших наработок по юзерленду на отдельные патчи к конкретным пакетам, или дополнительные пакеты. 2. добавление в portage ещё одного флага USE owl 3. копирование патчей в соотведствующие пакеты и правка ebuild файлов этих пакетов, чтобы при выборе пользователем флага owl накладывались патчи и проводились другие необходимые действия..
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	66. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от solardiz (ok) on 12-Янв-15, 19:12
	>> И в рамках какого проекта (или каких проектов)? > Свяжись с 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 не отвечает).
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	68. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Аноним (??) on 13-Янв-15, 11:02
	> Мы немного общаемся с конкретными ребятами "из Gentoo", но активно туда что-то > продвигать пока не пробовали. Не будучи хотя бы пользователем Gentoo, я > не стану сам что-то туда продвигать (разве что могу помочь советом, > если этим кто-то займется). Но если кто-то из нашей команды станет > - я только за. При других обстоятельствах может бы взялся за поддержку ваших патчей в Гентоо, но сей час мне не до этого. > Наши наработки и так в таком виде. Скорее работа потребуется по портированию > на другие (скорее всего, более новые) upstream-версии. Лучше продвигать в апстрим, так ваши наработки сразу появятся у всех дистрибутивах! Ребята "из Gentoo" часто общаются с разрабами о продвижении патчей в апстримы, возможно помогут.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	69. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от solardiz (ok) on 13-Янв-15, 11:20
	> Лучше продвигать в апстрим Для очевидных фиксов так и делаем. С требующими обсуждения/убеждения вещами - сложнее. > Ребята "из Gentoo" часто общаются с разрабами о продвижении патчей в > апстримы, возможно помогут. Gentoo нам уже немного помогли передав один из слотов в GSoC 2011 (от их организации - нашей) для продвижения hardening-патчей в mainstream ядро, что мы тогда немного и поделали: http://lwn.net/Articles/451405/ А "общаться с разрабами" всё же лучше непосредственно авторам предлагаемых изменений.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	71. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от Аноним (??) on 13-Янв-15, 13:05
	> http://lwn.net/Articles/451405/ Хотел задать ещё вопрос о ситуации с продвижением патчей grsecurity/PaX и Openwall в ядро, положение дел понял но не совсем ;) Есть патчи которые блягодаря современным процам абсолютно не влияют на производительность, также не добавляют видимой сложности поддержки кода. Мотивацию в отказе найти сложно, от АНБ selinux принимается, ваши наработки нет...
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	72. "Анонсирован Openwall GNU/*/Linux 3.1-stable"	+/–
	Сообщение от solardiz (ok) on 13-Янв-15, 17:35
	> Хотел задать ещё вопрос о ситуации с продвижением патчей grsecurity/PaX и Openwall > в ядро, положение дел понял но не совсем ;) Я когда-то частично это прокомментировал здесь: http://www.opennet.me/openforum/vsluhforumID3/70592.html#14 > Есть патчи которые блягодаря современным процам абсолютно не влияют на производительность, > также не добавляют видимой сложности поддержки кода. Мотивацию в отказе найти > сложно Часто бывают не то чтобы принципиальные отказы, а недовольство выбранным подходом и/или особенностями реализации. За несколько попыток, с переделками, отдельные вещи продвинуть можно. Если сразу не удается, то через год-другой можно тему поднимать повторно и пробовать еще раз - мнения upstream'а меняются. Но мало кто готов этим заниматься. И да, не 100% изменений (даже переделанных) таким образом примут, но, по моему мнению, могут принять еще многое. Разработчики grsecurity, как я понимаю, другого мнения - что-то вроде "пока такой-то, который говорил такие-то глупости, в том числе и недавно, участвует в принятии решений, пытаться что-то продвигать в ядро немного глупо и для нас унизительно, да мы и не хотим" (это моя интерпретация кучи отдельных твитов и комментариев, возможно я ошибаюсь). И дело тут не в одном "таком-то", конечно. Они на его высказывания ссылаются для примера. Но я вижу эту ситуацию не так черно-бело, как они. > от АНБ selinux принимается, ваши наработки нет... Кое-что принималось. Лично я и не пытался продвигать hardening-патчи при этом следуя всем правилам, так что мне не на что жаловаться. Когда мы пробовали продвигать патчи по правилам в рамках GSoC 2011 (фактически я, как ментор, поручил эту неблагодарную работу Василию), результат был умеренно положительным.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

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

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