| 1.1, Аноним (-), 11:25, 05/01/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
При сборке пакетов по умолчанию включены опции "-Wl,-z,relro" и "-Wl,-z"
"эпический вин" и как относится к безопасности не ясно.
| | |
| |
| 2.31, Аноним (-), 18:32, 05/01/2015 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> "эпический вин" и как относится к безопасности не ясно.
А ты попробуй hardening-check /your/executable - узнаешь для себя много нового.
| | |
|
| |
| 2.41, Michael Shigorin (ok), 01:33, 06/01/2015 [^] [^^] [^^^] [ответить]
| +/– |
 > штабильность! ©
>> Осуществлён переход на ядро Linux 2.6.18
С предыдущего, которое тоже "2.6.18" и тоже разве что по надписи на борту. Вы вообще читаете перед тем, как писать?..
| | |
|
| |
| 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 может использоваться как для создания высокозащищённых серверных систем, ..." не говорит, каким именно образом он должен использоваться.
Возможно, диск с дистрибутивом надо подкладывать куда-то под серверную стойку...
| | |
| |
| |
| 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
Ностальжи.
| | |
| |
| 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]#
| | |
| 2.29, Аноним (-), 18:16, 05/01/2015 [^] [^^] [^^^] [ответить]
| –3 +/– | |
> Десктоп параноика
Десктоп с ядром 2.6.18? Ну... если запускать это на той же машине что жидитоба реактос - тогда наверное нормально.
| | |
|
| |
| 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.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.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 -- включаем подсистему"; возможно, и Вам либо коллегам покажется интересным.
| | |
|
|
|
|
| 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.38, Amnesiac (?), 22:11, 05/01/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
не понял, а зачем этот древний vconfig?
разве "ip link add link eth0 name eth0.123 type vlan id 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, если что.
| | |
|
|
| |
| 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 принимается, ваши наработки нет...
| | |
|
|
|
|
|
|
|
