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

"Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+1 +/–
Сообщение от opennews (?), 29-Янв-20, 09:57
В развиваемом проектом OpenBSD почтовом сервере OpenSMTPD выявлена критическая уязвимость (CVE-2020-7247), позволяющая удалённо выполнить shell-команды на сервере с правами пользователя root. Уязвимость выявлена в ходе повторного аудита, проведённого компанией  Qualys Security (прошлый аудит OpenSMTPD проводился в 2015 году, а новая уязвимость присутствует с мая 2018 года). Проблема устранена в выпуске OpenSMTPD 6.6.2. Всем пользователям рекомендуется срочно установить обновление (для OpenBSD исправление можно  установить через syspatch)... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52267
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Spoofing (?), 29-Янв-20, 09:57	–7 +/–
это не уязвимость, повторяю, НЕ УЯЗВИМОСТЬ. в OpenBSD уязвимостей нет, а все сервисы что вы запускаете сами -- вы запускаете сами, повторяю, ЗАПУСКАЕТЕ САМИ.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #20, #80, #83, #132, #138

2. Сообщение от A.Stahl (ok), 29-Янв-20, 09:58	–11 +/–
Неуловимого Джо таки поймали. И при этом, к его большому огорчению, поймали не случайно, а ловили целенаправленно. Так что ему уже не отвертеться и ему будет очень больно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19

4. Сообщение от Аноним (4), 29-Янв-20, 10:02	+/–
На странице Goals их сайта первая же строка: "Be as secure as possible."
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #134

5. Сообщение от Аноним (5), 29-Янв-20, 10:08	+11 +/–
Найс аутотренинг
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #30

6. Сообщение от Анонимус2 (?), 29-Янв-20, 10:16	–2 +/–
>sh -c "" Вообще я бы за такое выгонял из профессии навсегда, но в секьюрном бсд видимо лучше знают как писать безопасно
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11

7. Сообщение от Аноним (7), 29-Янв-20, 10:30	+1 +/–
Просто нужно запретить создание произвольных процессов. Вместо этого при вызове приложения ему нужно передавать список разрешённых бинарников с их аргументами командной строки. Бинарники вызывать из программы по псевдониму, при этом передача аргументов командной строки запрещена. Весь говнокод отломается, туда ему и дорога. Придётся переписывать все программы на нормальную архитектуру: как разделяемые библиотеки с внешним API.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #84

11. Сообщение от Аноним (11), 29-Янв-20, 10:47	+3 +/–
Будьте так добры, накидайте ссылочек, как необходимо делать по вашему мнению.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #13, #22, #114

13. Сообщение от Нононим (?), 29-Янв-20, 10:54	+4 +/–
Оне выгонять учились, а не тому как надо делать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

15. Сообщение от Аноним (15), 29-Янв-20, 10:56	+10 +/–
Ага, все-таки можно настраивать сервер через SMTP! А то все SSH, да SSH...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #17

16. Сообщение от neAnonim (?), 29-Янв-20, 11:11	–4 +/–
Ну блин всегда так делал, а тут понабежали. Повторяю это НЕ БАГ, это фича.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #37

17. Сообщение от Аноним (17), 29-Янв-20, 11:15	+2 +/–
ЫХыххыхы :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

18. Сообщение от Аноним (18), 29-Янв-20, 11:44	–6 +/–
Неуловимый Джо отбегался по прериям...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #87

19. Сообщение от антикудах (?), 29-Янв-20, 11:47	+8 +/–
https://mobile.twitter.com/OpenSMTPD/status/1222288467046076417 А это он так пытается отвертеться, да? Задолбали ыксперты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

20. Сообщение от Дон Ягон (ok), 29-Янв-20, 12:21	+4 +/–
> это не уязвимость > в OpenBSD уязвимостей нет Разработчики OpenSMTPD говорят, что есть. Но тебе, конечно, виднее. "Qualys has found a critical vulnerability" ( https://www.mail-archive.com/misc@opensmtpd.org/msg0485... )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #24

21. Сообщение от Дон Ягон (ok), 29-Янв-20, 12:27	+3 +/–
Двоякие ощущения. С одной стороны хорошо, что нашли, с другой - похожее уже было, когда ж закончится? И тоже, кстати, Qualys нашли - https://www.opennet.ru/opennews/art.shtml?num=43090 (К разговору о том, что "за openbsd взялись всерьёз". Ага, взялись, ещё в 2015 году).
Ответить | Правка | Наверх | Cообщить модератору

22. Сообщение от Аноним (22), 29-Янв-20, 12:40	–3 +/–
Смотри postfix
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #25, #32, #109

23. Сообщение от Аноним (-), 29-Янв-20, 13:09	–4 +/–
Самая бестолковая из всех *bsd и этот хайп про безопасность... ОС для фанатиков - вот только эффект Плацебо тут не работает.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #38

24. Сообщение от XL (?), 29-Янв-20, 13:14	–6 +/–
Спасибо ребятам из Qualys, которые на деле показали, что OpenBSD мало чем отличается от других ОС в плане багов и уязвимостей. Искать какой-то мифической супер-пупер безопасности тут бессмысленно. Просто на эту ОС редко кто обращает внимание и мало кто ей пользуется - отсюда и мифы все. Типичные неуловимые Джо. Хотя лично я не удивлён. В наш век маркетинга, рекламы всё это довольно типично.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #26, #27, #53

25. Сообщение от Дон Ягон (ok), 29-Янв-20, 13:20	+1 +/–
> Смотри postfix Тот же postfix тоже позволяет запускать команду mda шеллом. https://github.com/vdukhovni/postfix/blob/master/postfix/src... https://github.com/vdukhovni/postfix/blob/master/postfix/src... Да, старается этого избегать, по возможности. Но сам факт - некоторую функциональность логичнее реализовывать именно так, а не писать свой недо-sh. Проблема не в том, что процесс OpenSMTPD запускает какие-то субкоманды шелом, а в том, что недостаточно хорошо проверяет входные данные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #41

26. Сообщение от Аноним (26), 29-Янв-20, 13:27	+4 +/–
Конечно, мало чем. Всего лишь реакцией за считанные дни и часы вместо замалчивания в течение месяцев.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

27. Сообщение от Дон Ягон (ok), 29-Янв-20, 13:30	+9 +/–
> Спасибо ребятам из Qualys, которые на деле показали, что OpenBSD мало чем отличается от других ОС в плане багов и уязвимостей. Ага, и не в первый раз уже. Как ни найдут дыру в OpenBSD, так сразу "на деле показали". Я тебе сейчас ещё на деле покажу, постарайся только со стула не упасть: https://www.cvedetails.com/vulnerability-list/vendor_id-97/O... Не благодари. > Искать какой-то мифической супер-пупер безопасности тут бессмысленно. "Мифическую супер-пупер безопасность" ищут только недалёкие дебилы. Защищаются от кого-то/чего-то, а дыры или прочие ошибки есть примерно во всём, что сделал человек. > В наш век маркетинга, рекламы всё это довольно типично. В наш век маркетинга и рекламы типично кукарекать не разобравшись в вопросе. "Безопасность по-умолчанию" - один из принципов производства OpenBSD - это история не про то, что в OpenBSD нет ошибок, а про то, что ошибки есть _ВЕЗДЕ_ и безопасные (читай: параноидально-минималистичные) настройки по-умолчанию - это способ по максимуму предотвратить эксплуатацию дыр, которые в системе по любому есть, просто про них ещё могут не знать. Например, благодаря тому, что OpenSMTPD по-умолчанию слушает только локалхост, мы имеем local root, а не remote root. А товарищам из Qualys действительно спасибо, они делом, а не словом помогают делать OpenBSD лучше и безопаснее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #28, #50

28. Сообщение от ssh (ok), 29-Янв-20, 13:38	+2 +/–
> Я тебе сейчас ещё на деле покажу, постарайся только со стула не упасть: https://www.cvedetails.com/vulnerability-list/vendor_id-97/O... Ты зачем сразу с козырей то зашел! :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

29. Сообщение от Аноним84701 (ok), 29-Янв-20, 13:43	+4 +/–
> в OpenBSD уязвимостей нет > что OpenBSD мало чем отличается от других ОС > но в секьюрном бсд >  ОС для фанатиков - вот только эффект Плацебо https://packages.debian.org/bullseye/opensmtpd https://centos.pkgs.org/7/epel-x86_64/opensmtpd-6.0.3p1-5.el... Хм, я так понимаю, что данная новость создавалась с целью сделать перепись местных "из принципа  прочитал только заголовок и первый абзац, но ценное мнение отпишу"? 🙄 Ну или принципиально не пользующихся тем же OpenSSH.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #39

30. Сообщение от pda (?), 29-Янв-20, 13:43	+5 +/–
Это не аутотренинг, это стёб над позицией разработчиков опёнка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #31

31. Сообщение от Дон Ягон (ok), 29-Янв-20, 13:50	+2 +/–
> это стёб над позицией разработчиков опёнка Демонстрирующий, главным образом, непонимание этой самой позиции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #131

32. Сообщение от Аноним (11), 29-Янв-20, 13:55	+/–
Спс
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

33. Сообщение от suffix (ok), 29-Янв-20, 14:15	–1 +/–
А как все на exim гнали когда полгода назад уязвимость у него выявили ! У всех такое бывает - а пользоваться надо чем удобнее !
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #34, #36

34. Сообщение от Дон Ягон (ok), 29-Янв-20, 14:25	+/–
> А как все на exim гнали когда полгода назад уязвимость у него выявили ! Всё-таки есть разница между наличием ошибок в принципе и положенным на безопасность болтом. Насчёт конкретно OpenSMTPD не могу предметно высказаться - когда мне приходилось настраивать почтовые серваки его ещё просто не было. Но тот же postfix - хороший вариант вместо exim, если его возможностей хватает. Remote root там, емнип, не находили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #137

36. Сообщение от Аноним (26), 29-Янв-20, 14:32	+1 +/–
Так вы посравнивайте, что и в каких количествах находили у exim в тот же период его существования. А если уж в нём и нынче находят эпические уязвимости, то...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #56

37. Сообщение от Аноним (37), 29-Янв-20, 14:42	+/–
Именно! АНБ просили "сделать возможнность", им сделали. А тут пришли какие-то анализаторы и нашли сделанное. Ну вот как после этого доверять всяким аудитам? А как же "национальная безопасность"? Она же важнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

38. Сообщение от Аноним (37), 29-Янв-20, 14:43	–1 +/–
Есть ещё NetBSD, которая без хайпа...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #40, #110

39. Сообщение от Аноним (37), 29-Янв-20, 14:49	–6 +/–
Этих шутов из OpenBSD имеет смысл содержать только ради openssh. Что, собственно, и происходит. Ихняя система никому нафиг не упала. Поддержка десктопов там условная, а поддержка серверов - печальная. А вот openssh используется везде. Но ведь нет возможности этим работягам дать гранты на целевое использование, они все там с тонкой душевной организацией, поэтому и отщепились в пользу опенбзд и сильно обижаются, когда им говоришь, что их содержат только ради openssh, а всё остальное - болезненный технологический нарост, нужный только им самим и только для них самих.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #43

40. Сообщение от Аноним (40), 29-Янв-20, 14:51	–2 +/–
> Есть ещё NetBSD, которая без хайпа... ... и без каких-либо заметных достоинств вообще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #42, #46, #85, #143

41. Сообщение от Ordu (ok), 29-Янв-20, 14:52	+5 +/–
> Проблема не в том, что процесс OpenSMTPD запускает какие-то субкоманды шелом, а в том, что недостаточно хорошо проверяет входные данные. Не совсем. То что он недостаточно хорошо проверяет -- это проблема. Но то, что он запускает субкоманды шеллом -- это тоже проблема. Если ты написал функцию pipe_to_mda(...) то эта функция должна запускать mda и только. Если при специально подобранных аргументах она может запустить не только mda, а ещё и "rm -rf /*", то это проблема. Может быть лишь потенциальная, но проблема. Безбажного кода не бывает -- все это знают, но мало кто понимает. То, что безбажного кода не бывает означает, что если твоя pipe_to_mda может при специально подобранных аргументах вызвать "rm -rf /*", то тебе не удастся доказать, что твоя программа не запустит "rm -rf /*" ни при каком вводе. Тут на деле встаёт вопрос ко всему проект OpenBSD: они не могут не знать, что exec на sh -- это штука, без которой сложно обойтись в unix. И они не могут не знать, что эта штука -- постоянный источник дыр в unix'овом софте. Если присмотреться, то корень проблемы в том, что при передаче аргументов через exec эти аргументы приходится кодировать в шелловские строки и чтобы sh потом декодировал их по своим заморочным правилам. То есть, образно говоря, надо собрать строку-скрипт и выполнить на неё eval. execle чуть лучше в этом смысле, чем system, но как показывает даже эта новость -- ненамного. И есть ведь напрашивающийся способ борьбы с этой проблемой: нужно взять и реализовать некое подмножество sh в виде C'шной библиотеки. Чтобы можно было бы написать, например: sh_c("mail.local", "-f", from, to) и быть уверенным, что это приведёт к тому, что будет создан процесс mail.local с argv вида {"mail.local", "-f", from, to}. Можно и с пайпами как-нибудь разрулиться, даже несмотря на убожество C, например: shellcommand_t base_cmd = sh_cmd("mail.local", "-f", from, to); shellcommand_t pipe_cmd = sh_pipe_from(command_input, base_cmd); sh_spawn(pipe_cmd); Да, из-за отсутствия параметризации типов в C, тут возможно придётся создавать типы чьи размеры будут неизвестны на этапе компиляции, и из-за этого придётся дёргать malloc почём зря, да ещё и оптимизации пойдут лесом, но, во-первых, может если подумать можно сделать всё не настолько плохо, во-вторых, какая разница: надо очень постараться, чтобы это получилось медленнее, чем старт шелла. Да, тут возможны проблемы с обработкой ошибок -- библиотека внутри будет дёргать много сисколлов, каждый из них может возвращать коды ошибок, и как-то надо эти ошибки прокидывать в код, дёргающий API библиотеки. Там опять же придётся повозиться и отсутствие параметризованных типов нисколько не упрощает эту возню. Но если всё совсем плохо, можно все сисколлы вызывать непосредственно из sh_spawn, и возвращать оттуда структурку описывающую результат, и к ней грядку методов для разгребания этого результата. Да, такая библиотечка не решит всех проблем. Например, если mail.local при специально подобранных from и to будет вызывать "rm -rf /*", то тут ничего не сделаешь на уровне библиотеки. Но фишка-то в том, что проблемы экранирования специсимволов шелла прекратят существовать. Потому что экранирование будет не нужно. Одна библиотека устраняет целый класс ошибок, довольно распространённых причём. Почему OpenBSD до сих пор не написала такую библиотеку и не перевела весь свой код на её использование, вместо всех этих system да execle -- мне не ясно. Подозреваю, что это юниксвей головного мозга.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #44

42. Сообщение от Дон Ягон (ok), 29-Янв-20, 14:56	+1 +/–
> и без каких-либо заметных достоинств вообще. Это, конечно же, не так. NetBSD вполне себе достойная ОС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #117

43. Сообщение от Хороним (?), 29-Янв-20, 14:57	+3 +/–
Перепиши openssh на своём любимом яваскрипте и тебе не придётся больше содержать "этих шутов". Денег сэкономиииишь!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

44. Сообщение от Дон Ягон (ok), 29-Янв-20, 15:13	+1 +/–
Для начала, спасибо за развёрнутое сообщение с текстом по существу вопроса. > Если ты написал функцию pipe_to_mda(...) то эта функция должна запускать mda и только. Если всё слишком хардкодить, получится прокрустово ложе. Даже postfix, в котором, насколько я вижу, сделано сильно больше, чтобы не запускать sh, даже он в некоторых случаях запускает его. > Если при специально подобранных аргументах она может запустить не только mda, а ещё и "rm -rf /*", то это проблема. Может быть лишь потенциальная, но проблема. Безусловно. > И они не могут не знать, что эта штука -- постоянный источник дыр в unix'овом софте. Знают. И даже пытаются валидировать входные данные, чтобы предотвратить это. Из-за ошибки в оной валидации проблема и возникла. > нужно взять и реализовать некое подмножество sh в виде C'шной библиотеки Я не понимаю, чем валидация данных в отдельной библиотеке лучше, чем в коде самого OpenSMTPD. Как допустить, так и недопустить ошибку можно в обоих случаях. Универсализация? Скорее всего, программы не являющиеся SMTP-демоном будут хотеть другие данные на вход и набор допустимых символов будет отличаться (и как бы не всецело). > Но фишка-то в том, что проблемы экранирования специсимволов шелла прекратят существовать. >  Почему OpenBSD до сих пор не написала такую библиотеку и не перевела весь свой код на её использование Насколько я могу понимать, никто не написал универсальную библиотеку, решающую проблемы экранирования спецсимволов на все случаи жизни. В любом случае, мне (лично мне) это не кажется очень простой задачей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #62

45. Сообщение от Аноним (11), 29-Янв-20, 16:03	+/–
Не пойму, что здесь многие уцепились, за BSD или за людей с недостаточным (или наоборот с излишне достаточным ;) опытом в вопросах безопасности. Вон товарисчь Бернштейн, взял да подошел к вопросу безопасности с другой стороны. Результат, как видно на лицо! И не цепляйтесь сразу к словам, результат именно в безопасности.
Ответить | Правка | Наверх | Cообщить модератору

46. Сообщение от 11 (?), 29-Янв-20, 16:16	+/–
> ... и без каких-либо заметных достоинств вообще. NetBSD и по безопасности (внезапно, да!?), и по сетевой подсистеме и по многим другим вещам наголову выше деревянной и упоротой OpenBSD. Просто там народ взрослый, опытный, спокойный и скромный. А компашка + Тео - толпа каких-то неврастеников с ЧСВ (не просто же так Тео выперли и команды NetBSD). NetBSD особо не рекламируют себя, тихо, мирно работают в своё удовольствие. То же самое касательно качества кода - поддержка вагона платформ обязывает писать унифицированный, хорошо продуманный код. НетБСД пишет профессура для души, а опенбсд/фрибсд пишут гики вроде Тео или какой-нибудь яндекс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #54, #55

47. Сообщение от VeryWideOpenBSD (?), 29-Янв-20, 16:18	–2 +/–
Заметил забавную тендецию, что в теме где встречается фэйлы про опенку очень знатно накручиваются минусики, лул. В 2020-м году что-то там накручивать. Согласен с товарищами выше, что Опенбсд это как неловимые джо. Обращают на них внимание - вагон багов, не обращают - ку-ка-ре-ку мост секурьюр ин зе ворлд, эт лист трайн то би зэ мост секурьюр ин зе ворлд ку-ка-ре-ку. Мне то лично всё равно, по барабану на опенку, но поведение сектантов умиляет. Чем бы дитя не тешилось.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #49

48. Сообщение от pin (??), 29-Янв-20, 16:22	–1 +/–
> вызове агента доставки (MDA) при помощи команды 'execle("/bin/sh", "/bin/sh" 🤦🤦🤦 21й век, а openBSD разрабы еще в 20м.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #58

49. Сообщение от Аноним (-), 29-Янв-20, 16:23	–2 +/–
Советую последить за Доном Ягоном, если он в новости, то обычно минусы встречаются даже в низу ленты комментариев. Хотя обычно на опеннете такое весьма редко. Обычно плюсуют/минусуют в топе ленты. > сектантов Сектанты есть сектанты. Они везде такие. Будь то пользователи OpenBSD или марксисты, либералы, социал-дарвинисты и прочие представители секс-меньшинств тп. Это уже чисто религиозный аспект. Логику тут искать бесполезно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #52, #60

50. Сообщение от Zulu (?), 29-Янв-20, 16:24	–6 +/–
> Например, благодаря тому, что OpenSMTPD по-умолчанию слушает только локалхост, мы имеем local root, а не remote root. То есть преимущество OpenBSD над другими системами это настройки по умолчанию? Т.е. OpenBSD это система для тех, кто не в состоянии настроить сервисы так, как ему нужно? Так вы этого слона не продадите.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #59, #66

51. Сообщение от Iron_ (?), 29-Янв-20, 16:29	–2 +/–
Почитал тему. К чему эти бессмысленные простыни текста от юзеров опёнка? Какие-то козыри, какие-то ссылки. Что за детский сад? С таким кодом разрабы OpenBSD знатно опозорились. Примитивизм ошибок + убогое качество кода.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #57, #64, #106

52. Сообщение от Аноним (-), 29-Янв-20, 16:35	+1 +/–
> Советую последить за Доном Ягоном, если он в новости, то обычно минусы > встречаются даже в низу ленты комментариев. Хотя обычно на опеннете такое > весьма редко. Обычно плюсуют/минусуют в топе ленты. Советую проследить за анонимами! Если они в новости, то минусы встречаются везде! Причем, с бессмысленной и беспощадной накруткой, как недавно: https://www.opennet.ru/openforum/vsluhforumID3/119501.html#41 (упомянули о том, что Distrowatch вообще-то на фре и получили коммент "вы все врети и вообще это не нужный сайт" и -22 )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

53. Сообщение от OpenEcho (?), 29-Янв-20, 16:55	+1 +/–
>Просто на эту ОС редко кто обращает внимание и мало кто ей пользуется - отсюда и мифы все. Т.е. General Motors, JPL не в счет ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #61

54. Сообщение от Дон Ягон (ok), 29-Янв-20, 16:55	+4 +/–
При всех моих симпатиях к NetBSD (как и к прочим BSD-системам), в комментарии написана чушь. Начиная от противопоставления NetBSD OpenBSD, заканчивая попытками обосновать высказанное. > NetBSD и по безопасности (внезапно, да!?), и по сетевой подсистеме и по многим другим вещам наголову выше деревянной и упоротой OpenBSD А как ты сравниваешь, например, безопасность? По количеству CVE? По количеству интегрированных средств снижения вреда от эксплуатации уязвимостей? По количеству оных, включённых по-умолчанию? По количеству исследований? Сравниваешь ли всё это с аудиториями проектов? Честно, я не знаю, что безопаснее, NetBSD или OpenBSD (или какая-то ещё ОС). Факторов, которые нужно учитывать очень много, это тебе не попугаями в бенчмарках меряться. Но, безусловно, NetBSD уделяет значительное внимание безопасности. > Просто там народ взрослый, опытный, спокойный и скромный. А компашка + Тео - толпа каких-то неврастеников с ЧСВ (не просто же так Тео выперли и команды NetBSD). Стесняюсь спросить, а как же ты тогда оцениваешь перенос некоторого кода из OpenBSD в NetBSD? И нет, я даже не про OpenSSH. А, например, про bioctl и pf (уже переписаны). Про tmux. Про systrace, который хоть и был запилен (емнип) Провосом из NetBSD, пилился обеими командами. Все BSD-системы обмениваются кодом (особенно, когда речь о драйверах) и NetBSD с OpenBSD - не исключения. Тео "выперли" из NetBSD по административным причинам и отнюдь не все это одобряли. И многие с ним ушли. И "взрослый и опытный народ" и "толпа неврастеников" прекрасно взаимодействуют на пользу друг другу. И вообще не в курсе, что должны враждовать. > NetBSD особо не рекламируют себя, тихо, мирно работают в своё удовольствие. Ну да, а баннеры OpenBSD на каждом сайте уже просто прохода не дают. Ну да, а разработчики NetBSD просят, нет, просто умоляют удалять любые упоминания о них в СМИ. И twitter не ведут. > поддержка вагона платформ обязывает писать унифицированный, хорошо продуманный код Или держать в коде костыли/поддержку легаси/сложнодиагностируемые баги, говори уж до конца. Поддержка 100500 платформ не должна быть самоцелью. OpenBSD, например, тоже поддерживает более 10 архитектур в надежде ловить странные ошибки (иначе наличие поддержки того же PA-RISC сложно обосновать - кому он не для тестов может быть нужен?), но когда ресурсов на поддержку чего-либо нет - дропают. Например, недавнее - https://undeadly.org/cgi?action=article;sid=20191003043450. Не то, чтобы это сильно позитивно, но SGI-то уже точно труп... > НетБСД пишет профессура для души, а опенбсд/фрибсд пишут гики вроде Тео или какой-нибудь яндекс. Большой дебилизм заниматься подобного рода противопоставлением. И NetBSD и OpenBSD хорошие ОС. Со своими плюсами и минусами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #93

55. Сообщение от Аноним (55), 29-Янв-20, 17:04	+/–
От openssh ты конечно уже отказался?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #92

56. Сообщение от Аноним (55), 29-Янв-20, 17:07	+/–
То что?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #119

57. Сообщение от Аноним (55), 29-Янв-20, 17:09	+1 +/–
А вы, простите, кто, что бы оценки раздавать качеству кода?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

58. Сообщение от Аноним (55), 29-Янв-20, 17:10	+/–
Ага, в 21 веке shell же отменили, на новый год президент как раз выступал с этим заявлением.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #75

59. Сообщение от Дон Ягон (ok), 29-Янв-20, 17:12	+1 +/–
> То есть преимущество OpenBSD над другими системами это настройки по умолчанию? Это один из способов снижения вреда от уязвимостей. Естественно, всех проблем не решающий. > Т.е. OpenBSD это система для тех, кто не в состоянии настроить сервисы так, как ему нужно? Не знаю, как на это ответить. Тем более, что это явный троллинг. Попробуйте обосновать, зачем бы OpenSMTPD по-умолчанию слушать что-то отличное от localhost, когда не получится, возможно, станет понятно, о чём я.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #69, #89

60. Сообщение от Дон Ягон (ok), 29-Янв-20, 17:18	+3 +/–
> Советую последить за Доном Ягоном, если он в новости, то обычно минусы встречаются даже в низу ленты комментариев. Естественно я ставлю минусы тем, кто пишет херню (с моей точки зрения; в мере понимания вопроса стараюсь свою позицию обосновывать или хотя бы понятно высказывать). Не принимай мои минусы (не знаю, правда, как отличить их от чужих) близко к сердцу, я всего лишь анонимный опеннетчик.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #97

61. Сообщение от Дон Ягон (ok), 29-Янв-20, 17:22	+/–
> Т.е. General Motors, JPL не в счет ? Можно каких-то пруфов? Не то, чтобы я сомневаюсь или не верю, просто люблю, когда пруфы есть, а сходу ничего не нагуглилось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #78

62. Сообщение от Ordu (ok), 29-Янв-20, 17:43	+/–
> Я не понимаю, чем валидация данных в отдельной библиотеке лучше, чем в коде самого OpenSMTPD. Во-первых, там не нужна валидация. Нельзя сказать, чтобы совсем не нужна, но сравни: execle("/usr/libexec/mail.local", "mail.local", "-f", from, to); и execle("/bin/sh", "sh", "-c", "/usr/libexec/mail.local", "-f", from, to) Разница между этими вариантами в том, что во втором последние четыре аргумента читаются шеллом из его argv и _интерпретируются_, прежде чем передаются в mail.local. Это будто мы взяли и чисто по фану на каждый аргумент вызвали некий аналог eval, под названием shell expansion (который с радостью выполнит команду, если её записать в виде $(rm -rf /*) или `rm -rf /*`). Чтобы этого избежать во втором варианте, мы включаем экранирование, чтобы после shell expansion'а, mail.local получил бы именно то, что исходно лежало в переменных from и to, а не что-то иное. Или иными словами: мы знаем, что на from и to будет вызвана функция expand и в mail.local будут переданы аргументы expand(from) и expand(to), но нам надо передать from и to, поэтому мы создаём функцию unexpand, такую что \forall x expand(unexpand(x)) == x, и после этого мы передаём в mail.local значения expand(unexpand(from)) и expand(unexpand(to)). В первом варианте мы непросредственно прокидываем содержимое from и to в mail.local через егойный argv, нам не нужен unexpand, потому что нет никакого expand. Но мы лишаемся шелловского job control'а, что становится особенно болезненным, если нам надо через пайпы что-то прокидывать в вызываемую команду, или через пайпы же вычитывать вывод вызываемой команды. Но, как бы там не было, в обоих случае вызываемая программа должна валидировать вход. Как она это делает -- мы не знаем, и это нас не касается. Может быть программа складывает значения в sql базу данных, и поэтому значения from и to надо экранировать по sql-правилам экранирования. Может быть она создаёт файл с именем from, и поэтому ей надо что-то сделать с from, преобразовать в строку которая может быть именем файла. Но это уже проблемы вызываемой программы. (точнее в идеале именно она должна этим заниматься, иногда это невозможно или слишком сложно, но не в том случае, о котором новость). То есть, валидация нужна, но это не должно быть заботой вызывающего кода. Вызывающий код должен обрабатывать ошибки, а не валидировать вход. Во-вторых, даже если бы валидация от шелла и нужна была бы, то она была бы нужна в библиотеке, которой пользуются многие. В этой библиотеке были бы баги, но одни на всех. Устранение бага в библиотеке устраняет баги у всех. Ресурсы вложенные в аудит кода, в тестирование кода разными методами будут возвращаться всем проектам. Если мы представим на секундочку модель разработки софта, в которой многие проекты вызывают шелл, и каждый проект вкладывает какое-то количество ресурсов в то, чтобы обезбажить этот вызов шелла, и сравним её с моделью, в которой есть единая библиотека, чей API гарантирует отсутствие багов, баги могут скрываться лишь в реализации, и в обезбаживание этой реализации вкладывается суммарное количество ресурсов, которое в первой модели вкладывалось в обезбаживание частных реализаций, то какой вариант будет безбажнее? Да, тут есть свои подводные камни: баг, найденный в библиотеке, сделает уязвимыми многие программы. Но system и exec("sh", ...) -- это весьма распространённые штуки в *nix, то есть существует множество людей заинтересованных в том, чтобы делать это максимально надёжно и безопасно, а значит можно вбухать реально много ресурсов в то, чтобы продумать API и вылизать реализацию. Плюс не обязательно внедрять эту библиотеку сразу везде и в продакшн. Можно форкнуть заинтересованные проекты и тащить пару лет форки, крича на всех углах о том, какие у нас безопасные форки, провоцируя других на то, чтобы они доказывали бы нам, насколько глубоко мы ошибаемся. Некоторые доказательства будут сопровождаться эксплоитами, что будет очень полезно нам. Через несколько несовместимых переписываний API мы доберёмся до v1.0, и тогда... Но для этого нужно, чтобы за проектом стояла организация типа OpenBSD, которая давала бы маркетинга и оплачивала бы хотя бы одного квалифицированного программиста на полную занятость. > Насколько я могу понимать, никто не написал универсальную библиотеку, решающую проблемы экранирования спецсимволов на все случаи жизни. Я говорю не об универсальной библиотеке, экранирующая спецсимволы, я говорю о /bin/sh в виде подгружаемой библиотеки. В некотором смысле, семантически это sh, но с другим синтаксисом. Этот синтаксис более многословный и неудобный для использования в командной строке, и вообще без компиляции с ним не поработаешь. Зато он оптимизирован на избегание _распространённых_ проблем вызванных ошибками экранирования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #86, #90

63. Сообщение от Аноним (63), 29-Янв-20, 17:44	+/–
Эй фряшники как победить? trueos aks freebsd 13 checking whether gmake sets $(MAKE)... yes checking for gcc... gcc9 checking whether the C compiler works... no configure: error: in `/usr/ports/emulators/wine-devel/work/wine-5.0-rc6': configure: error: C compiler cannot create executables
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #67

64. Сообщение от Дон Ягон (ok), 29-Янв-20, 17:46	+/–
> К чему эти бессмысленные простыни текста от юзеров опёнка? А в чём смысл этих срывов покровов про безопасность OpenBSD почти в каждой теме про оную? А в темах про уязвимости оной - так точно в каждой. И ладно бы что-то по делу писали, так ведь поток откровенной тупни. Остальное комментировать не буду, по остальным моим комментариям в этой теме и так уже должно быть всё понятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

65. Сообщение от Аноним (63), 29-Янв-20, 17:48	+/–
===>  Configuring for wine-devel-5.0.r6,1 configure: loading site script /usr/ports/Templates/config.site checking build system type... amd64-portbld-freebsd13.0 checking host system type... amd64-portbld-freebsd13.0 checking whether gmake sets $(MAKE)... yes checking for gcc... gcc9 checking whether the C compiler works... no configure: error: in `/usr/ports/emulators/wine-devel/work/wine-5.0-rc6': configure: error: C compiler cannot create executables
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #71, #121

66. Сообщение от Аноним (66), 29-Янв-20, 18:00	+/–
Мы и не продаём "слона".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

67. Сообщение от анонн (ok), 29-Янв-20, 18:04	+/–
> Эй фряшники как победить? trueos aks freebsd 13 Что там "aka"-то? И почему не в более подходящей, соседней новости о MPV (там есть подветка обсуждения аниме) > checking whether gmake sets $(MAKE)... yes > checking for gcc... gcc9 > checking whether the C compiler works... no > configure: error: in `/usr/ports/emulators/wine-devel/work/wine-5.0-rc6': > configure: error: C compiler cannot create executables например, проверить на noexec-mount FS для WRKDIRPREFIX портов? Потом - обосновать религиозные заморочки, не позволяющие установить вайн пакетом из репы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #76

68. Сообщение от Аноним (63), 29-Янв-20, 18:08	+/–
тут про bsd, права кругом дефолтные и версию wine хочу новее.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #107

69. Сообщение от Zulu (?), 29-Янв-20, 18:09	+/–
> Попробуйте обосновать, зачем бы OpenSMTPD по-умолчанию слушать что-то отличное от localhost, когда не получится, возможно, станет понятно, о чём я. Я стараюсь намекнуть на то, что безопасность надо сравнивать при сопоставимых функциях, без этого получается сравнение теплого с мягким, поэтому фраза "Например, благодаря тому, что OpenSMTPD по-умолчанию слушает только локалхост, мы имеем local root, а не remote root" бессмысленна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #74

70. Сообщение от Аноним (63), 29-Янв-20, 18:10	+/–
>проверить на noexec-mount FS как это сделать?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #79

71. Сообщение от Аноним (71), 29-Янв-20, 18:10	+2 +/–
У вас компилятор бракованый, видимо пиратская версия
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

72. Сообщение от Аноним (63), 29-Янв-20, 18:14	+/–
fstab # Device                Mountpoint              FStype          Options Dump Pass /dev/label/swap0.eli    none            swap    sw      0       0 zfs (
Ответить | Правка | Наверх | Cообщить модератору

73. Сообщение от Аноним (63), 29-Янв-20, 18:15	+/–
>У вас компилятор бракованый, видимо пиратская версия понятно bsd не моё(( спасибо всем
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #108

74. Сообщение от Дон Ягон (ok), 29-Янв-20, 18:24	+/–
>> Попробуйте обосновать, зачем бы OpenSMTPD по-умолчанию слушать что-то отличное от localhost, когда не получится, возможно, станет понятно, о чём я. > Я стараюсь намекнуть на то, что безопасность надо сравнивать при сопоставимых функциях, без этого получается сравнение теплого с мягким, поэтому фраза "Например, благодаря тому, что OpenSMTPD по-умолчанию слушает только локалхост, мы имеем local root, а не remote root" бессмысленна. Смотря в каком контексте рассматривать. Если речь об использовании OpenSMTPD как полноценного почтового сервера, то да, знанием о дефолте можно пренебречь, т.к. всё равно придётся заставить его слушать что-то отличное от localhost. Если речь об OpenSMTPD как о стандартном локальном smtpd в базовой системе OpenBSD, то это имеет смысл, так как на значительном числе конфигураций у нас будет только local root, что не так фатально опасно, как RCE.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

75. Сообщение от pin (??), 29-Янв-20, 18:48	+/–
Ну да, писать на C и дергать из него shell. Месье знает толк.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #105

76. Сообщение от Аноним (76), 29-Янв-20, 19:00	+/–
Что за дичь, кто вайном из репы пользуется? Там такое-то шерето в коде по дефолту…
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #77

77. Сообщение от анонн (ok), 29-Янв-20, 19:26	+/–
> Что за дичь, кто вайном из репы пользуется? Там такое-то шерето в коде по дефолту… И шерето магически исчезнет, если собрать самому из портов?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #94

78. Сообщение от OpenEcho (?), 29-Янв-20, 19:30	+1 +/–
Информация инсайдерская, поэтому сорри, пруфов не будет, хотите верьте, хотите нет, хотя если интересно, попробуйте https://enlyft.com/tech/products/openbsd
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #81

79. Сообщение от анонн (ok), 29-Янв-20, 19:31	+/–
>>проверить на noexec-mount FS как > это сделать? посмотреть в вывод mount? mount ... tmpfs on /tmp (tmpfs, local, noexec, nosuid) tmpfs on /tmp-wrk (tmpfs, local, nosuid) /dev/gpt/cache on /cache (ufs, local, noatime, soft-updates) проверить права доступа к дефолтному сборочному диру WRKDIRPREFIX: make -V WRKDIRPREFIX /fooba по умолчанию это /usr/ports или прописать сборочный дир самому: echo WRKDIRPREFIX=/tmp-my-wrkdir >> /etc/make.conf так же, желательно писать ответ переходом по ссылке "ответить" для отображения того в виде дерева и уведомлений учавствующих об ответе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #99

80. Сообщение от Аноним (80), 29-Янв-20, 19:34	–1 +/–
Разумеется. Это вебмакаки опять тру ветеранам сишникам из BSD баги в код залили. Шелл, юникс и си не при чем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #116

81. Сообщение от Дон Ягон (ok), 29-Янв-20, 19:37	+/–
> Информация инсайдерская, поэтому сорри, пруфов не будет, хотите верьте, хотите нет Ничего в моей жизни не изменится от того, поверю я или нет. Также ничего не изменится от того, является ли эта информация правдой или ложью. Интересен как раз опыт и/или практический пример успешного использования. А так - да я может быть и верю, а толку то? ИМХО, нет смысла приводить подобные примеры без каких-либо пруфов. Даже если это правда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #82

82. Сообщение от OpenEcho (?), 29-Янв-20, 19:45	+/–
>ИМХО, нет смысла приводить подобные примеры без каких-либо пруфов. Даже если это правда. Полностью согласен, sorry, просто обидно за опенку стало, сорвалось... Надеюсь линк сверху "немного" подтвердит мои слова...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

83. Сообщение от Аноним (83), 29-Янв-20, 19:58	+1 +/–
+15 – поняли очевидный сарказм -23 – не поняли
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

84. Сообщение от Аноним (83), 29-Янв-20, 20:02	+/–
SELinux это умеет? Или другое решение?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #103, #115, #159

85. Сообщение от Аноним (83), 29-Янв-20, 20:03	+/–
Она работает на VAX! И на тостерах!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

86. Сообщение от Дон Ягон (ok), 29-Янв-20, 20:04	+/–
> Разница между этими вариантами в том, что во втором последние четыре аргумента читаются шеллом из его argv и _интерпретируются_, прежде чем передаются в mail.local. Это будто мы взяли и чисто по фану на каждый аргумент вызвали некий аналог eval, под названием shell expansion (который с радостью выполнит команду, если её записать в виде $(rm -rf /*) или `rm -rf /*`). Описанная проблема понятна, её разработчики OpenSMTPD пытаются решать списком допустимых символов и эскейпингом. Т.е. вызвать тот же rm таким способом, как ты описал, в конкретном случае не получилось бы. > Но, как бы там не было, в обоих случае вызываемая программа должна валидировать вход. > То есть, валидация нужна, но это не должно быть заботой вызывающего кода. Вызывающий код должен обрабатывать ошибки, а не валидировать вход. Но ведь в данном случае, вызываемая программа и есть /bin/sh. И проблема не в том, что мы передали что-то не то в /usr/libexec/mail.local, а в том, что мы завершили shell-команду символом ";" и выполнили (ошибочно) кусок того, что после ";" с правами локального юзера, которому предназначалось письмо. > Я говорю не об универсальной библиотеке, экранирующая спецсимволы, я говорю о /bin/sh в виде подгружаемой библиотеки. В некотором смысле, семантически это sh, но с другим синтаксисом. Этот синтаксис более многословный и неудобный для использования в командной строке, и вообще без компиляции с ним не поработаешь. Зато он оптимизирован на избегание _распространённых_ проблем вызванных ошибками экранирования. Я несколько неверно высказался, что проблема в неверной валидации входных данных. Ну то есть это так, но "[функция] smtp_mailaddr() имеет логическую ошибку, из-за которой в случае передачи пустого домена в email, функция возвращает успешный код проверки, даже если часть адреса до "@" содержит недопустимые символы" - это не то, что можно было бы пофиксить условной libsh. Я вообще не уверен, что есть серебрянная пуля, защищающая от подобного рода ошибок. Условная libsh, в зависимости от того, как она будет сделана, может быть и будет решать какие-то типовые проблемы, в то же время, ИМХО, в бОльшей части случаев практичнее просто ответственно подходить к валидации входных данных, а не использовать комплексные решения (unix-way головного мозга, да).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #102

87. Сообщение от Аноним (87), 29-Янв-20, 20:16	+/–
И ни меча, ни лат, и лицом в салат до утра - вот и все дела...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

88. Сообщение от DAV (?), 29-Янв-20, 20:24	+/–
Все хором проигнорировали фразу "в соответствии с требованиями RFC 5322". Отдельно стоящий я -- могу плевать на RFC при настройке почтовика, а вот мантейнер не может... И про использование. Видел в хедерах Сбера строку с OpenSmtpd.
Ответить | Правка | Наверх | Cообщить модератору

89. Сообщение от sstj3n (?), 29-Янв-20, 20:37	+1 +/–
Зачем тогда в принципе устанавливать программу, которая  в дефолтных настройках бесполезна в 99 случаях из ста? Сравнивать надо именно конфигурации, полезные большинству. Так-то и sshd можно на локалхост повесить в дистре и объявить его "самым безопасТъным". Ну да, безопасно, а толку-то с него?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #91

90. Сообщение от Дон Ягон (ok), 29-Янв-20, 20:54	+/–
>> Но, как бы там не было, в обоих случае вызываемая программа должна валидировать вход. >> То есть, валидация нужна, но это не должно быть заботой вызывающего кода. Вызывающий код должен обрабатывать ошибки, а не валидировать вход. > Но ведь в данном случае, вызываемая программа и есть /bin/sh. И проблема не в том, что мы передали что-то не то в /usr/libexec/mail.local, а в том, что мы завершили shell-команду символом ";" и выполнили (ошибочно) кусок того, что после ";" с правами локального юзера, которому предназначалось письмо. Ну да, в случае libsh (условного), мы бы вызывали саму программу. Но тогда бы да, были бы проблемы по меньшей мере с пайпами. И не было бы проблем с эскейпингом и т.п. > Если мы представим на секундочку модель разработки софта, в которой многие проекты вызывают шелл, и каждый проект вкладывает какое-то количество ресурсов в то, чтобы обезбажить этот вызов шелла, и сравним её с моделью, в которой есть единая библиотека, чей API гарантирует отсутствие багов, баги могут скрываться лишь в реализации, и в обезбаживание этой реализации вкладывается суммарное количество ресурсов, которое в первой модели вкладывалось в обезбаживание частных реализаций, то какой вариант будет безбажнее? Вот честно - не знаю. Решить общую задачу, как правило, сложнее, чем частную. Потому что придётся рассматривать значительно бОльшее количество возможных кейсов (я КО, да).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

91. Сообщение от Дон Ягон (ok), 29-Янв-20, 21:05	+2 +/–
> Зачем тогда в принципе устанавливать программу, которая  в дефолтных настройках бесполезна в 99 случаях из ста? Сравнивать надо именно конфигурации, полезные большинству. Так-то и sshd можно на локалхост повесить в дистре и объявить его "самым безопасТъным". Ну да, безопасно, а толку-то с него? *вздыхает* Ты не знаешь, зачем нужен локальный почтовик в юниксах? UPD: И да, блин, sshd по-умолчанию вообще выключен. И это тоже абсолютно верный подход по снижению вреда от возможных дыр в sshd. Безусловно, не спасающий тех, кто пользуется sshd. Подсказка: на десктопе, например, многим он не нужен. В том числе тем, кто не полезет разбираться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #112, #113, #122, #155

92. Сообщение от Аноним (-), 29-Янв-20, 21:11	+/–
> От openssh ты конечно уже отказался? Отродясь не пользовался.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #98

93. Сообщение от Аноним (-), 29-Янв-20, 21:12	–2 +/–
Опять словоблудие... Ещё себе пару плюсиков поставь... Секта она и есть секта...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #96

94. Сообщение от Аноним (76), 29-Янв-20, 21:19	+/–
>> Что за дичь, кто вайном из репы пользуется? Там такое-то шерето в коде по дефолту… > И шерето магически исчезнет, если собрать самому из портов? Нужно немножко поправить "юзы", тогда исчезнет. Большая часть потенциально уязвимых фич никогда никакому софту не нужна. Совершенно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

95. Сообщение от Аноним (63), 29-Янв-20, 21:19	+/–
пиратская всё таки Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:4655: $? = 0 configure:4644: gcc9 -v >&5 Using built-in specs. COLLECT_GCC=gcc9 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/lto-wrapper Target: x86_64-portbld-freebsd13.0 Configured with: /wrkdirs/usr/ports/lang/gcc9/work/gcc-9.2.0/configure --enable-multilib --with-build-config=bootstrap-debug --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc9 --libexecdir=/usr/local/libexec/gcc9 --program-suffix=9 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-in> Thread model: posix gcc version 9.2.0 (FreeBSD Ports Collection) configure:4655: $? = 0 configure:4644: gcc9 -V >&5 gcc9: error: unrecognized command line option '-V' gcc9: fatal error: no input files compilation terminated. configure:4655: $? = 1 configure:4644: gcc9 -qversion >&5 gcc9: error: unrecognized command line option '-qversion'; did you mean '--version'? gcc9: fatal error: no input files compilation terminated. configure:4655: $? = 1 configure:4675: checking whether the C compiler works configure:4697: gcc9 -O2 -pipe  -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc9 -isystem /usr/local/include -fno-strict-aliasing  -isystem /usr/local/include  -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc9 -L/usr/local/lib/gcc9  conftest.c -L/usr/local/lib >&5 /usr/local/bin/ld: cannot find /usr/lib/libc_nonshared.a /usr/local/bin/ld: cannot find /usr/lib/libssp_nonshared.a collect2: error: ld returned 1 exit status configure:4701: $? = 1 configure:4739: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "Wine" | #define PACKAGE_TARNAME "wine" | #define PACKAGE_VERSION "5.0-rc6" | #define PACKAGE_STRING "Wine 5.0-rc6" | #define PACKAGE_BUGREPORT "wine-devel@winehq.org" | #define PACKAGE_URL "https://www.winehq.org" | /* end confdefs.h.  */ | | int | main () | { | |   ; |   return 0; | } configure:4744: error: in `/var/tmp/usr/ports/emulators/wine-devel/work/wine-5.0-rc6': configure:4747: error: C compiler cannot create executables See `config.log' for more details
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #101, #126

96. Сообщение от Дон Ягон (ok), 29-Янв-20, 21:25	+/–
Зато ты предельно конкретен, ага. Сколько надо, столько и поставлю, у тебя спрошу только когда ты научишься аргументировать мысли, а не переходить на личности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

97. Сообщение от lorovec (?), 29-Янв-20, 21:26	–2 +/–
> Естественно я ставлю минусы тем, кто пишет херню Так-то пока херню тут пишешь только ты. Причём огромные простыни потока сознания. Агрясь на любые комменты, даже вполне безобидные. > стараюсь свою позицию Ну типа речь не о тебе вообще. Причём тут ты? Речь о том, что опёнок довольно среднестатистическая ос с точки зрения безопасности. Фанатики этот факт принять к сведению всё никак не могут. > Не принимай мои минусы (не знаю, правда, как отличить их от чужих) близко к сердцу Вообще всё это. Плюсы, упорные минусы другим. Даже дети такой херней не будут маяться. Чисто религиозная история. Хочешь плюсиков? Ну держи плюсик.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #100, #104

98. Сообщение от Аноним (98), 29-Янв-20, 21:33	+3 +/–
>> От openssh ты конечно уже отказался? > Отродясь не пользовался. дропбер + путти + локалхост онли одмин = твое все?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #118

99. Сообщение от Аноним (63), 29-Янв-20, 21:36	+/–
с расстройства не сделал ответом. log (
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

100. Сообщение от Дон Ягон (ok), 29-Янв-20, 21:49	+1 +/–
>> Естественно я ставлю минусы тем, кто пишет херню > Так-то пока херню тут пишешь только ты. Причём огромные простыни потока сознания. Агрясь на любые комменты, даже вполне безобидные. Ну раз ты так сказал... >> стараюсь свою позицию > Ну типа речь не о тебе вообще. Причём тут ты? Речь о том, что опёнок довольно среднестатистическая ос с точки зрения безопасности. Фанатики этот факт принять к сведению всё никак не могут. Даже если так, то не по той причине, что там нашли (о, Боже, Боже) дыру. Дыры есть везде. То, что разработчики ужесточают настройки по-умолчанию и пытаются внедрять проактивные способы защиты от эксплуатации уязвимостей свидетельствует о том, что они понимают, что писать код без ошибок они не умеют, хотя и стараются. Выводы позволю сделать прочитавшему сие самостоятельно. >> Не принимай мои минусы (не знаю, правда, как отличить их от чужих) близко к сердцу > Вообще всё это. Плюсы, упорные минусы другим. Даже дети такой херней не будут маяться. Чисто религиозная история. Хочешь плюсиков? Ну держи плюсик. Даже не знаю, что на это ответить. Пожалуй, скажу "спасибо". Спасибо!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

101. Сообщение от анонн (ok), 29-Янв-20, 22:02	+/–
>/usr/local/bin/ld: cannot find /usr/lib/libc_nonshared.a >/usr/local/bin/ld: cannot find /usr/lib/libssp_nonshared.a >collect2: error: ld returned 1 exit status >configure:4701: $? = 1 >configure:4739: result: no > configure: failed program was: Чей-то тут не то: uname -rs FreeBSD 12.1-STABLE % locate libc_nonshared /usr/lib/libc_nonshared.a /usr/lib32/libc_nonshared.a % locate libssp_nonshared /usr/lib/libssp_nonshared.a /usr/lib32/libssp_nonshared.a /usr/local/lib/gcc/mingw32/4.8.1/libssp_nonshared.a /usr/local/lib/gcc5/libssp_nonshared.a /usr/local/lib/gcc7/libssp_nonshared.a /usr/local/lib/gcc8/libssp_nonshared.a /usr/local/lib/gcc9/libssp_nonshared.a /usr/local/lib32/gcc8/libssp_nonshared.a /usr/local/lib32/gcc9/libssp_nonshared.a Обе либы, кстати, входят в "базу" https://download.freebsd.org/ftp/releases/amd64/12.1-RELEASE... так что бросайте уже эту Vasyano-Zver-Edition, ну или не удивляйтесь глюкам при попытке использовать не только как запускалку браузера или файлохранилище.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

102. Сообщение от Ordu (ok), 30-Янв-20, 00:27	+/–
>> Разница между этими вариантами в том, что во втором последние четыре аргумента читаются шеллом из его argv и _интерпретируются_, прежде чем передаются в mail.local. Это будто мы взяли и чисто по фану на каждый аргумент вызвали некий аналог eval, под названием shell expansion (который с радостью выполнит команду, если её записать в виде $(rm -rf /*) или `rm -rf /*`). > Описанная проблема понятна, её разработчики OpenSMTPD пытаются решать списком допустимых > символов и эскейпингом. Т.е. вызвать тот же rm таким способом, как > ты описал, в конкретном случае не получилось бы. Да, но и тем не менее логическая ошибка в коде экранизации привела к возможности эксплуатации этой ошибки. Никакого запаса прочности. Сколько ещё ненайденных ошибок прячется в коде экранизации? Есть ли быстрый надёжный способ найти все code-path ведущие к этому execle и доказать, что во всех этих случаях экранизация выполняется верно? Где гарантия, что будущие правки кода не создадут кодопути к этому execle, которые нарушат допущения и засунут туда неэкранированные строки? > Я несколько неверно высказался, что проблема в неверной валидации входных данных. Ну > то есть это так, но "[функция] smtp_mailaddr() имеет логическую ошибку, из-за > которой в случае передачи пустого домена в email, функция возвращает успешный > код проверки, даже если часть адреса до "@" содержит недопустимые символы" > - это не то, что можно было бы пофиксить условной libsh. Так уж и не мог бы пофиксить? В случае с условной libsh этот инвалидный почтовый адрес ушёл бы бэкэнду, тот бы либо переслал дальше, либо сообщил о несуществующем адресе. Я не к тому, что ошибку с синтаксически кривым адресом будет более правильным обрабатывать в mda_agent, чем в MTA -- хз, на самом деле: бекенду всё равно нужно проверить валидность, почему бы не свалить эту проверку на него и не париться о ней? -- но, как минимум, при таком раскладе класс опасности ошибки был бы существенно ниже. > Я вообще не уверен, что есть серебрянная пуля, защищающая от подобного рода > ошибок. > Условная libsh, в зависимости от того, как она будет сделана, может быть > и будет решать какие-то типовые проблемы, в то же время, ИМХО, > в бОльшей части случаев практичнее просто ответственно подходить к валидации входных > данных, а не использовать комплексные решения (unix-way головного мозга, да). Бороться с каждой ошибкой в отдельности -- это хорошо, но выделять классы ошибок и использовать AoE спеллы против них -- это гораздо эффективнее. Да, AoE -- не серебряная пуля, но они высвобождают ресуры под то, чтобы бороться с ошибками, которые нам ещё не удалось прибить AoE оружием. Бывают AoE "спеллы", которые требуют, например, кучу дополнительной памяти, или ещё как-то повышают требования к железу, или вообще сильно не бесплатны. Но здесь "плата" за AoE -- это виртуально однократно вложенные усилия в разработку libsh. Никаких накладных расходов в runtime, более того потенциально могут быть возможности срезать эти накладные расходы в рантайме.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #129

103. Сообщение от Аноним (7), 30-Янв-20, 00:31	+/–
Нет, не умеет. Это capability-based security. См. не взлетевший cloudABI.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

104. Сообщение от Аноним (26), 30-Янв-20, 01:09	+1 +/–
Это я, ленивый Перерезус (лень логиниться), пока ещё агрюсь. И ловлю кучу минусов от User294 и ему подобных гениев, которым в принципе неправильно всё, чем они сами не пользуются. А вот у Дона Ягона лично я как раз учусь выдержке. И вам советую.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #120, #127, #139

105. Сообщение от Аноним (26), 30-Янв-20, 01:10	+/–
Действительно, когда уже execve() сделают deprecated?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #141

106. Сообщение от Аноним (26), 30-Янв-20, 01:11	+1 +/–
А сколько уязвимостей мсье нашёл в чужом коде, чтобы так авторитетно говорить, можно поинтересоваться? Просто интересно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

107. Сообщение от Аноним (26), 30-Янв-20, 01:13	+1 +/–
Как пропатчить KDE2 тогда уж спрашивайте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

108. Сообщение от Аноним (26), 30-Янв-20, 01:14	+1 +/–
Не ваше. Вы не умеете в домашнюю работу — вы идёте лесом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

109. Сообщение от Аноним (109), 30-Янв-20, 01:14	+/–
> Будьте так добры, накидайте ссылочек, как необходимо делать по вашему мнению. > Смотри postfix В postfix было так: https://www.exploit-db.com/exploits/34896 Уязвимость в bash CVE-2014-6271. А подход в postfix такой же. Смотрите тогда уж qmail.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

110. Сообщение от Аноним (-), 30-Янв-20, 01:58	+/–
> NetBSD, которая без хайпа... У NetBSD нет слогана и она оплачивает аудит (http://blog.netbsd.org/tnf/entry/network_security_audit). У OpenBSD есть слоган и ей проводят аудит бесплатно. Ну и кто тут лох?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

111. Сообщение от Аноним (111), 30-Янв-20, 06:57	+/–
https://download.freebsd.org/ftp/snapshots/amd64/13.0-CURRENT/ отсюда взял базу, распаковал и скопировал /usr/lib, теперь все норм. Спасибо за идею! Буду грызть ее зубами, потому что она хорошая ))))
Ответить | Правка | Наверх | Cообщить модератору

112. Сообщение от sstj3n (?), 30-Янв-20, 10:31	+/–
Речь не о том, зачем он там нужен, а о том, насколько он необходим для функционирования системы. Иначе мы докатимся так до какого-нибудь alpine Linux и скажем, что там по умолчанию вообще нет ни хрена => сие есть самая безопасТная система! Прожить, скажем, без отправки сообщений в локальный ящик пользователя из крона какого-нибудь вполне себе можно. Пример с sshd приведен в контексте массового  использования системы в качестве сервера чего-либо. Понятно, что openbsd пока в этот контекст не вписывается ( да и надо ли ? ). С другой стороны, почему бы тогда не позиционировать опёнка в нише домашних настольных ПК?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #123

113. Сообщение от Анонимус2 (?), 30-Янв-20, 11:21	+/–
Зачем вообще локальному почтовику слушать smtp? Насколько я помню в debian exim вообще не слушает ничего по умолчанию, sendmail(1) работает - и достаточно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

114. Сообщение от Анонимус2 (?), 30-Янв-20, 11:35	+/–
Не делать вызов sh программно вообще никогда, не видел пока ни одной программы сложнее hello world где бы это не привело к уязвимостям. В данном случае - вызывать mail.local напрямую, без обёртки в виде шелла. Если уж администратору сильно захотелось запустить шелл - ему нужно дать возможность вместо mail.local запустить произвольный файл, пусть пишет его на чем угодно - хоть шелл, хоть си, хоть джаваскрипт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #135

115. Сообщение от phaoost (ok), 30-Янв-20, 11:39	+/–
SELinux в OpenBSD???
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #136

116. Сообщение от Michael Shigorin (ok), 30-Янв-20, 12:53	+2 +/–
Мсье сейчас, разумеется, расскажет, как от ЛОГИЧЕСКИХ ошибок в АЛГОРИТМЕ страхует какой-нить silverbulletLanguage.  Ну или балабол, как водится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #130

117. Сообщение от Michael Shigorin (ok), 30-Янв-20, 12:57	+/–
Как минимум там есть Чеусов ;-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #125

118. Сообщение от Michael Shigorin (ok), 30-Янв-20, 12:58	+/–
Тогда скорее "Далее, далее, далее, ОК"? :]
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98

119. Сообщение от Michael Shigorin (ok), 30-Янв-20, 12:59	+/–
То сидите дальше на своей пороховой бочке, только не удивляйтесь, что менее склонные к самоподрыву люди обходят вас обеих на безопасном расстоянии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

120. Сообщение от Michael Shigorin (ok), 30-Янв-20, 13:03	+/–
Пора перебарывать лень; привет :) А на User294 не обижайся, его я покусал, когда меня инфраоранжевоглазики типа never@ задолбали вот вообще совсем, а из вменяемых разве что netch@ и Кабаев попались.  Думаю, пример конструктивных людей говорит сам за себя (и в каждом сообществе важна именно их доля).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #140

121. Сообщение от Michael Shigorin (ok), 30-Янв-20, 13:04	+1 +/–
См. config.log, но лучше сразу ставьте минт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

122. Сообщение от Аноним (122), 30-Янв-20, 13:24	+1 +/–
> *вздыхает* > Ты не знаешь, зачем нужен локальный почтовик в юниксах? И зачем, если локально хватает MTA типа DMA? man dma > dma – DragonFly Mail Agent >  dma is a small Mail Transport Agent (MTA), designed for home and office use. >  It accepts mails from locally installed Mail User Agents (MUA) and >  delivers the mails either locally or to a remote destination.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #124

123. Сообщение от Дон Ягон (ok), 30-Янв-20, 13:34	+/–
> Речь не о том, зачем он там нужен, а о том, насколько он необходим для функционирования системы. В стандартной поставке он нужен (рутовые нотификации), далее ты можешь настроить себе всё как хочешь. > Иначе мы докатимся так до какого-нибудь alpine Linux и скажем, что там по умолчанию вообще нет ни хрена => сие есть самая безопасТная система! Обрати внимание - никто не считает, что тот факт, что по-умолчанию smtpd слушает только localhost делает ОС "самой безопасной ОС". Ты опровергаешь собственные домыслы. > Пример с sshd приведен в контексте массового  использования системы в качестве сервера чего-либо. И к чему он? Речь про адекватность настроек по-умолчанию. А рассматривать всерьёз сервера без ssh или чего-то аналогичного (я хз чего) - просто идиотизм. > Понятно, что openbsd пока в этот контекст не вписывается Ты хочешь сказать, что серверов под OpenBSD не бывает?) > С другой стороны, почему бы тогда не позиционировать опёнка в нише домашних настольных ПК? OpenBSD система общего назначения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #142, #154

124. Сообщение от Дон Ягон (ok), 30-Янв-20, 13:37	+1 +/–
>> *вздыхает* >> Ты не знаешь, зачем нужен локальный почтовик в юниксах? > И зачем, если локально хватает MTA типа DMA? > man dma DMA - очень хороший вариант, да (и вообще стрекоза мне нравится). В OpenBSD вместо него OpenSMTPD, слушающий только localhost, т.е. урезанный до +/- аналогичного простого функционала.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

125. Сообщение от Дон Ягон (ok), 30-Янв-20, 13:45	+/–
> Как минимум там есть Чеусов ;-) Мне это мало о чём говорит. Погуглил, нашёл про nih (пакетный менеджер), вспомнил, что когда-то читал про это и ещё что-то. Но и только. Но, в любом случае, NetBSD  - это хорошо ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117

126. Сообщение от Дон Ягон (ok), 30-Янв-20, 13:55	+/–
> /usr/local/bin/ld: cannot find /usr/lib/libc_nonshared.a > /usr/local/bin/ld: cannot find /usr/lib/libssp_nonshared.a Подозреваю, что вы намудрили с опциями сборки (gcc9 как бы намекает). Возможно, от процитированного поможет редактирование /usr/lib/libc.so, но 1) Если точно не понятно, что вы делаете, лучше ничего не делайте, а не то доломаете всё. 2) Это не самое изящное и бескостыльное решение 3) Я довольно давно не играл в игрули с FreeBSD и, возможно, безбожно вру. Проверьте написанное мной, прежде чем что-то делать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

127. Сообщение от Дон Ягон (ok), 30-Янв-20, 13:59	+/–
Спасибо на добром слове, коли не шутите.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

129. Сообщение от Дон Ягон (ok), 30-Янв-20, 14:38	+/–
Сори за долгий ответ, не хотелось отвечать совсем не подумав. > Есть ли быстрый надёжный способ найти все code-path ведущие к этому execle и доказать, что во всех этих случаях экранизация выполняется верно? Я такого способа не знаю. > Где гарантия, что будущие правки кода не создадут кодопути к этому execle, которые нарушат допущения и засунут туда неэкранированные строки? Гарантий нет. > Так уж и не мог бы пофиксить? В случае с условной libsh этот инвалидный почтовый адрес ушёл бы бэкэнду, тот бы либо переслал дальше, либо сообщил о несуществующем адресе. Я не к тому, что ошибку с синтаксически кривым адресом будет более правильным обрабатывать в mda_agent, чем в MTA -- хз, на самом деле: бекенду всё равно нужно проверить валидность, почему бы не свалить эту проверку на него и не париться о ней? -- но, как минимум, при таком раскладе класс опасности ошибки был бы существенно ниже. Всё верно. Но и корректная логика валидации в текущем снизила бы класс опасности ошибки? > Бороться с каждой ошибкой в отдельности -- это хорошо, но выделять классы ошибок и использовать AoE спеллы против них -- это гораздо эффективнее. Да, AoE -- не серебряная пуля, но они высвобождают ресуры под то, чтобы бороться с ошибками, которые нам ещё не удалось прибить AoE оружием. > Но здесь "плата" за AoE -- это виртуально однократно вложенные усилия в разработку libsh. В теории я согласен с тобой. На практике я не уверен, что платой будут однократно вложенные усилия - могу допустить, что чинить ошибки придётся очень долго или бесконечно. Это если речь про условную универсальную libsh. Но на самом деле, я сегодня с утра задумался о том, почему я вообще завёл про это речь. Кажется, более адекватно было бы рассматривать не условный libsh, а возможность использовать какой-то dsl или даже условный python. Но и тут приходится (имхо) выбирать между двумя крайностями: * Готовый язык (типа python), вероятно, as-is будет слишком мощный и его придётся огораживать, примерно также, как сейчас огораживается shell. * DSL, который, в теории, можно написать строго под свои задачи, и который может и не содержать лишнего. Если отказаться от универсализации, то могу согласиться, что это может быть и более хорошим вариант, чем текущий. Универсальный вариант у меня по-прежнему вызывает сомнения, в том плане, что разработка подобного мне кажется долгим и сложным мероприятием, без гарантий достижения желаемых целей. Может я неправ, да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

130. Сообщение от Аноним (80), 30-Янв-20, 15:37	–2 +/–
Простите, Михаил, но тут не какие-то абстрактные логические ошибки. Конкретно этот дефект следует из самой сути философии юникс, тут сошлись три столпа: шелл, си и то, что с целью упрощения код можно писать на о....сь. Этот баг КРАЙНЕ юниксвеен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116 Ответы: #133

131. Сообщение от pda (?), 31-Янв-20, 03:08	+/–
Так разъясните. Они любят заострять внимание на "Only two remote holes in the default install, in a heck of a long time!". А что у них включено по умолчанию? ntpd и sshd? Очешуенный сервер. Так и я могу. Напишу сейчас "hello world" и в нём за 100500 лет не найдут ни одной удалённой уязвимости. Только какой в этом толк? Или я чего-то не понимаю?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #145

132. Сообщение от Аноним (-), 31-Янв-20, 06:57	+/–
Э, вот пардон, сервис под "маркой" OpenSMTPD изначально маркетировавшийся как "секурный", код типа 'execle("/bin/sh", "/bin/sh", "-c", mda_command,...' Как-то вообще совсем не украшает. Это вот это вот - дизайнилось для секурити? Вот прям с командой шеллу формируемой из данных отгруженных пользователей? И, кстати, нафиг эта штука под рутом работает? Объясните наивному - что в его функциональности требует рут?! А то я глупый линуксоид и не догоняю зачем такой программе рут вперся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #147

133. Сообщение от Аноним (-), 31-Янв-20, 06:59	+/–
Это какой-то очень специфичный вариант юниксвэя - так странно sh звать прямо хардкодом стремной конструкции в коде сишной проги. Если в опенке где-то и есть security in mind - то явно не в таком фрагменте кода как зацитирован. Вызывать шелл с юзерскими данными затея заведомо ссыкотная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #150, #153

134. Сообщение от Аноним (-), 31-Янв-20, 07:07	+/–
Что-то 'execle("/bin/sh", "/bin/sh", "-c", mda_command,...' не выглядит в этом ключе, уж сорри.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #151

135. Сообщение от Аноним (-), 31-Янв-20, 07:11	+/–
Во-во. А если какие-то параметры отдать надо - то наверное все-таки не в sh -c, такая конструкция заведомо заявка на залет. Шелл больно уж много всего специально трактует так что кормить его из недоверяемых данных - чего, рута по DHCP все уже забыли, мыло было?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

136. Сообщение от Аноним (-), 31-Янв-20, 07:14	+/–
У них, кстати, pledge есть. Он что, не умеет лимитировать параметры сисколов? Впрочем если юзерь может в sh -c как рут, толку с этого будет довольно маргинально, любой кулхацкер за 10 минут с -c изобразит что-нибудь годное даже так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

137. Сообщение от Аноним (-), 31-Янв-20, 07:17	+/–
sh -c с параметрами сформированными из юзерских данных так и хочется назвать болтом забитым на безопасность, или курением на бочке с порохом. Сам не понимаю почему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #149

138. Сообщение от Аноним (-), 31-Янв-20, 07:50	+/–
#define BUG FEATURE, мде? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

139. Сообщение от Аноним (-), 31-Янв-20, 08:31	+/–
> И ловлю кучу минусов от User294 и ему подобных гениев, Перерезус, просто для сведений... 1) Я технически не могу ставить минусы: JS тут наглухо зарублен. Так что честное слово, это не я. 2) В последнее время если я что-то поливаю то стараюсь аргументировать. Или если это не получается - стараюсь воздерживаться от поливания, ибо антипаттерн. 3) Меня на опеннете не было этак с год, ибо отвисание на опеннете учит плохому и жрет время которое можно потратить сильно полезнее. 4) Я таки распознаю право других индивидов хоть йайцы к мостовой прибивать покуда это не создает крупных проблем другим. А учиться выдержке лучше всего у Кроа-Хартмана. Если конкретно в контексте BSD - можно посмотреть как он невероятно политкорректно завернул кого-то из BSD, сказав что-то типа того что мол, у вас дескть, тоже неплохие системы, но мне кажется что по моему мнению мы как команда можем и еще лучше, дескать, поэтому мне так и сяк нравится линух. И наверное цивилизованные дискуссии взрослых людей должны быть ближе к какому-то такому формату, а не...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

140. Сообщение от Аноним (-), 31-Янв-20, 08:33	–1 +/–
Меня одно время тоже задолбали BSDшники вопящие в всех ветках про линух. И вот тут им на самом деле надо жаловаться на самих себя прежде всего - потому что изначально агрессия перла от этих господ. Особенно от фряшников. Начиная с эпохи раннего становления пингвина - попадались весьма неадекватные артефакты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120

141. Сообщение от Аноним (-), 31-Янв-20, 08:35	+/–
Execve с параметрами из юзерского ввода вообще стремноватая затея, а когда там к тому же sh -c - это примерно как гранатой в футбол играть, с аргументом "но мы же проверили, чека на месте". А оказалось - все-равно может сдетонировать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #152

142. Сообщение от sstj3n (?), 31-Янв-20, 09:43	+/–
Как же туго-то... Суть примеров: если то, что ты называешь "адекватными настройками", существенно урезает возможность использования core functionality софта, то называть это "адекватными настройками" как-то странновато, и уж тем более говорить о том, что это есть mitigation для проблемы. Переводя пример с sshd в плоскость opensmtpd: нахрена мне  _по_умолчанию_ в системе сервис, предназначенный в том числе для релеинга писем за пределы локалхоста, но которым я не могу воспользоваться без повышения уровня опасности уязвимости ? Класть нотификации в локальный mbox можно более простыми способами, без россказней об "адекватности настроек", а софт просто снести нафиг за ненадобностью, ибо самая безопасный сервис в системе по умолчанию - это потушенный сервис, либо его отсутствие. Посыл: считать существенное урезание функционала софта через "адекватные настройки" в поставке по умолчанию преимуществом есть некорректность и не более чем маркетинговый ход, поэтому упоминать это как некое преимущество есть глупость
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #146

143. Сообщение от Аноним (-), 31-Янв-20, 09:51	+/–
> ... и без каких-либо заметных достоинств вообще. HammerFS? Единственные из BSDшников кто смог хотя-бы попытаться сделать приличную современную файловую систему...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #148

144. Сообщение от Аноним (144), 31-Янв-20, 13:23	+/–
Доломал и фряху поставил, но как собрать wine5 с поддержкой в том числе и 32бит для новых игр или хотябы новую версию пусть только и 32бит, а то там 4.0 i386-wine-devel?
Ответить | Правка | Наверх | Cообщить модератору

145. Сообщение от Дон Ягон (ok), 31-Янв-20, 14:53	+/–
> Так разъясните. Они любят заострять внимание на "Only two remote holes in the default install, in a heck of a long time!". А что у них включено по умолчанию? ntpd и sshd? Очешуенный сервер. > Так и я могу. Напишу сейчас "hello world" и в нём за 100500 лет не найдут ни одной удалённой уязвимости. Только какой в этом толк? "Only two remote holes in the default install, in a heck of a long time!" - это слоган проекта, да. Толк в безопасном default install в том, что это минимальный признак безопасности ОС. Подчёркиваю: не максимальный, а минимальный. Если ОС дырява изкоробки, уже не факт, что важно, что её можно настроить безопасно - наплевательский подход уже продемонстрирован. И дыра может быть использована до того, как ты её пофиксишь правильными настройками. Да, большие дяди собирают (зачастую) свой дистрибутив ОС и кастомизируют настройки под себя, и для них это не актуально. Но этими людьми мир не ограничивается. Сейчас с этим получше, а раньше многие дистрибутивы linux (и не только) запускали по дефолту всякое, что потом успешно эксплуатировалась, ибо было дыряво или настроено "гениями". Искренне не понимаю, почему слоган вызывает такое количество волнений. Там прямым текстом написано про default install - не понимаю, как можно обмануться и подумать, что наличие каких либо других дыр разработчики игнорируют. Можно открыть http://www.openbsd.org/errata66.html (чиселку в конце поменять в зависимости от версии) и убедиться, что это не так. Дисклеймер: я в себе уверен, но всё-таки я высказываю личное мнение, а не офф. позицию разработчиков OpenBSD.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #156

146. Сообщение от Дон Ягон (ok), 31-Янв-20, 15:50	+/–
> Суть примеров: если то, что ты называешь "адекватными настройками", существенно урезает возможность использования core functionality софта, то называть это "адекватными настройками" как-то странновато, и уж тем более говорить о том, что это есть mitigation для проблемы. Ты или слушаешь в пол уха или не хочешь понимать меня, похоже. Core functionality урезается не в принципе, а только в поставке по-умолчанию. Если мы говорим о продукте OpenSMTPD, то да, это практически никак не влияет на его безопасность, потому что первое, что в нём включат - "слушать не только localhost". Если мы говорим о продукте OpenBSD, то ограниченность OpenSMTPD локалхостом влияет на безопасность продукта. Не все используют OpenBSD исключительно как почтовый сервер, а local root, гораздо лучше, чем remote root. Хотя тоже плохо, да. > Переводя пример с sshd в плоскость opensmtpd: нахрена мне  _по_умолчанию_ в системе сервис, предназначенный в том числе для релеинга писем за пределы локалхоста, но которым я не могу воспользоваться без повышения уровня опасности уязвимости ? А что, есть способ поднять на машине сервис, слушаюший/пишущий в сеть, не подняв уровень опасности для сервера? Очевидно, что сервер, слушающий сеть менее безопасен, чем сервер, который этого не делает. Очевидно, что если тебе нужен полноценный почтовый сервер, тебе придётся устанавливать ПО, которое умеет в smtp не только на локалхосте. > Класть нотификации в локальный mbox можно более простыми способами, без россказней об "адекватности настроек", а софт просто снести нафиг за ненадобностью, ибо самая безопасный сервис в системе по умолчанию - это потушенный сервис, либо его отсутствие. Ну то есть ты предлагаешь вместо одного потенциально уязвимого сервиса сделать два (или более) потенциально уязвимых сервиса, я всё правильно понял? Ещё раз: если функциональность нужна, она всё равно будет включена, тем или иным способом. И в её реализации может быть уязвимость. > Посыл: считать существенное урезание функционала софта через "адекватные настройки" в поставке по умолчанию преимуществом есть некорректность и не более чем маркетинговый ход, поэтому упоминать это как некое преимущество есть глупость Точно? То есть, если бы OpenSMTPD, например, по-умолчанию позволял бы без какой либо проверки любому внешнему пользователю отправить письмо с любого адреса - ты бы высказывался в таком же духе? Минималистичные настройки по-умолчанию - это не серебрянная пуля, как и все прочие митигации. Безопасность - это комплексный процесс и каждая отдельно взятая мера - это кусок пазла. Глупо ждать, что настройки по-умолчанию решат все проблемы или отменят найденную уязвимость (типа той, про которую пост). Ещё более глупо - делать из этого вывод, что настройки в стиле "воруй-убивай, можно всё" по-умолчанию могут привести к чему-то хорошему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142

147. Сообщение от Дон Ягон (ok), 31-Янв-20, 17:21	+/–
> Э, вот пардон, сервис под "маркой" OpenSMTPD изначально маркетировавшийся как "секурный", > код типа > >  'execle("/bin/sh", "/bin/sh", "-c", mda_command,...' > > Как-то вообще совсем не украшает. Это вот это вот - дизайнилось для > секурити? Вот прям с командой шеллу формируемой из данных отгруженных пользователей? > И, кстати, нафиг эта штука под рутом работает? Объясните наивному - > что в его функциональности требует рут?! А то я глупый линуксоид > и не догоняю зачем такой программе рут вперся. Qmail: "When a mail message arrives, qmail-local runs sh -c command in your  home  directory." ( http://manpages.ubuntu.com/manpages/xenial/man8/qmail-comman... ) "args[0] = "/bin/sh"; args[1] = "-c"; args[2] = prog; args[3] = 0;" ( https://github.com/c-rack/qmail/blob/master/qmail-local.c#L263 ) Postfix: https://github.com/vdukhovni/postfix/blob/master/postfix/src... https://github.com/vdukhovni/postfix/blob/master/postfix/src... И postfix, и qmail проектировались с акцентом на безопасность. Проблема не непосредственно в том, что вызывается sh -c. Мне лично кажется, что хотя бы для рута есть смысл огородить это, но глубоко я в код не погружался и не побожусь, что для такого поведения нет оснований.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132

148. Сообщение от Дон Ягон (ok), 31-Янв-20, 17:24	+/–
> HammerFS HAMMER разрабатывается в DragonflyBSD, Мэттом Диллоном и компанией. В NetBSD UFS+WAPBL и порт zfs (хз, насколько готовый к проду в сравнении с FreeBSD/ZoL - не тестировал).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143

149. Сообщение от Дон Ягон (ok), 31-Янв-20, 17:32	+/–
> sh -c с параметрами сформированными из юзерских данных так и хочется назвать болтом забитым на безопасность, или курением на бочке с порохом. Процитирую сам себя: Qmail: "When a mail message arrives, qmail-local runs sh -c command in your  home  directory." ( http://manpages.ubuntu.com/manpages/xenial/man8/qmail-comman... ) "args[0] = "/bin/sh"; args[1] = "-c"; args[2] = prog; args[3] = 0;" ( https://github.com/c-rack/qmail/blob/master/qmail-local.c#L263 ) Postfix: https://github.com/vdukhovni/postfix/blob/master/postfix/src... https://github.com/vdukhovni/postfix/blob/master/postfix/src... И postfix, и qmail проектировались с акцентом на безопасность. > Сам не понимаю почему. Потому что твоё желание ложное. Проблема не непосредственно в том, что вызывается sh -c. Популярные безопасные почтовые серверы postfix и qmail делают то же самое, и подобных проблем в них не было найдено. Вызывать из кода стороннюю программу с произвольными аргументами и не создать проблем с безопасностью в любом случае сложно, с sh или без.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137

150. Сообщение от Дон Ягон (ok), 31-Янв-20, 17:50	+/–
https://www.opennet.ru/openforum/vsluhforumID3/119631.html#147
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133

151. Сообщение от Дон Ягон (ok), 31-Янв-20, 17:51	+/–
> Что-то 'execle("/bin/sh", "/bin/sh", "-c", mda_command,...' не выглядит в этом ключе, уж сорри. https://www.opennet.ru/openforum/vsluhforumID3/119631.html#147
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134

152. Сообщение от Дон Ягон (ok), 31-Янв-20, 17:52	+/–
https://www.opennet.ru/openforum/vsluhforumID3/119631.html#147
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141

153. Сообщение от Аноним (80), 31-Янв-20, 18:50	+/–
Это юниксвей тот самый, изначальный, лазоревый, который worse is better. Простота лучше правильности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133

154. Сообщение от Дон Ягон (ok), 01-Фев-20, 03:00	+/–
> рутовые нотификации В смысле письма от всяких демонов на root@$host. Как мне показалось, формулировка неудачная и требует уточнения. Как правило рутовая почта - это алиас.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123

155. Сообщение от Дон Ягон (ok), 01-Фев-20, 03:19	+/–
> sshd по-умолчанию вообще выключен Я обманул, инсталлятор спрашивает о том, запускать по дефолту или нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

156. Сообщение от pda (?), 03-Фев-20, 00:42	+/–
> Искренне не понимаю, почему слоган вызывает такое количество волнений. Потому что выглядит как попытка ввести в заблуждение. Люди ожидают от "default install" то, что устанавливается/доступно в поставке от разработчиков. Они гордятся собой - молодцы. Любому пользователю опёнка от этого ни горячо ни холодно. Любая система, повторюсь, ставится для чего-то. Для практической эксплуатации. Так что для пользователей честный слогон не "всего две уязвимости за дцать лет", а "у нас бывают дырки, как и у всех".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #157

157. Сообщение от Дон Ягон (ok), 03-Фев-20, 12:39	+/–
>> Искренне не понимаю, почему слоган вызывает такое количество волнений. > Потому что выглядит как попытка ввести в заблуждение. Для кого? Для тех, кто не умеет читать? Для тех кто не в курсе про наличие тематических рассылок и приведённой мною в прошлом сообщении ссылки? Тогда не жалко, что они вводятся в заблуждение, ничего личного. > Люди ожидают от "default install" то, что устанавливается/доступно в поставке от разработчиков. Не распарсил. В любом случае, подозреваю, что разные люди ждут разного от default install. > Любому пользователю опёнка от этого ни горячо ни холодно. Я предлагаю не высказываться за любого пользователя опёнка. Мне, например, сильно нравится, что после установки ОС мне нужно включать нужное, а не выключать ненужное и что думать нужно, главным образом, об безопасной настройке стороннего ПО, а не о безопасности и стороннего ПО и ОС. > Любая система, повторюсь, ставится для чего-то. Для практической эксплуатации. И что? Оценить "дырявость" всех возможных конфигураций не представляется возможным, это очевидно. OpenSSH, позволяющий рутовый логин с паролем - это уже почти что приглашение логиниться всем и каждому. Ничто не мешает пользователю это включить (или вообще поднять telnet, без шифрования) - это всё тоже что ли будет говорить о небезопасности ОС? Слоган ничего не обещает про нестандартные конфигурации, и это логично и последовательно - разработчики ОС предоставляют надёжную (насколько возможно) базу, все что настроил пользователь - зона его ответственности. > Так что для пользователей честный слогон не "всего две уязвимости за дцать лет", а "у нас бывают дырки, как и у всех". Это как раз абсолютно бессмысленный слоган, если не сказать "по-настоящему идиотский". Любой, кто всерьёз сомневался в том, что в OpenBSD бывают уязвимости (как у всех, ага), по большому счёту, не должен париться ни из-за слогана, ни из-за OpenBSD вообще. ОЧЕВИДНО, что во всём, хоть немного сложном, что сделал человек есть ошибки, дыры и прочие радости жизни. Ну серьёзно, я не верю, что человек, которому небезразлична безопасность ОС, прочитал слоган и "обманулся", а не пошёл и не написал в гугле (или где-то ещё) "openbsd cve" и не открыл первую ссылку. Никого не волнует, что, например, “Of course it runs NetBSD”, если буквоедствовать и придираться, является ложью (ну правда, какой-нибудь эльбрус в нативном режиме; наверняка есть и менее хардкорные примеры), зато, почему-то, всех волнует что "было только две дыры в стандартной поставке и т.д." != "не было дыр никогда и нигде". Хотя написано всё прямым текстом, в отличие от. Чудеса, да и только.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156

158. Сообщение от Дон Ягон (ok), 03-Фев-20, 12:40	+/–
Разработчик OpenSMTPD опубликовал разбор ситуации с уязвимостью и некоторые соображения по предотвращению подобного в будущем: https://poolp.org/posts/2020-01-30/opensmtpd-advisory-dissected/
Ответить | Правка | Наверх | Cообщить модератору

159. Сообщение от исчо_адын_гентушнег (?), 04-Фев-20, 16:22	+/–
>SELinux это умеет? Или другое решение? на селе можно, но для 99%  цЫкурити-админов сильно сложно ( ибо редхад методички в редхад включают только таргет полиси). А так да, отловить exec* сель может, аргументы тоже. На настоящей RBASC -  как 2 пальца об асфальт, но они все платные
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

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

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