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

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

"Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
Сообщение от opennews (??) on 25-Июл-11, 19:03
Для защиты от возможных ошибок в сторонних модулях аутентификации (например, удаленная root-уязвимость (http://www.opennet.me/opennews/art.shtml?num=31053) через OpenSSH в старых версиях FreeBSD из-за ошибки в libopie), разработчики OpenBSD реализовали (http://undeadly.org/cgi?action=article&sid=20110721123003) новый режим изоляции "UsePrivilegeSeparation=sandbox", работающий на стадии до начала аутентификации и сброса привилегий. Пока метод работает только в OpenBSD и использует систему systrace для ограничения числа допустимых системных вызовов. В будущих выпусках OpenBSD представленная опция будет использована по умолчанию. При использовании данной защиты в случае поражения через уязвимость в  OpenSSH злоумышленник не сможет организовать атаку на локальную систему (например, эксплуатировать локальную уязвимость в ядре) и другие хосты (создать сокет, запустить прокси и т.п.). URL: http://undeadly.org/cgi?action=article&sid=20110721123003 Новость: http://www.opennet.me/opennews/art.shtml?num=31286
Ответить | Правка | Cообщить модератору

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

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

1. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+1 +/–
Сообщение от anonymous (??) on 25-Июл-11, 19:03
Хорошо, что openssh развивается. А в линухах такая радость появится? И когда, если да?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от Xasd (ok) on 25-Июл-11, 19:07
	> В будущих выпусках OpenBSD представленная опция будет использована по умолчанию.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от Vitto74 (ok) on 25-Июл-11, 19:09
	Исходник доступен, OpenSSH в Linux есть. Скоро будет.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	4. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+1 +/–
	Сообщение от Аноним (??) on 25-Июл-11, 19:17
	Насколько я знаю, в Linux абсолютно точно такой же технологии - нет. Поэтому на портирование данной конкретной фичи за пределы OpenBSD рассчитывать не стоит. Но у пингвинов есть куда более мощный и гибкий SELinux, и система ограничений основных серверных демонов (а не только sshd) там существует уже давно.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	5. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+1 +/–
	Сообщение от Аноним (??) on 25-Июл-11, 19:22
	>Но у пингвинов есть куда более мощный и гибкий SELinux, и система ограничений основных серверных демонов (а не только sshd) там существует уже давно. И это в то время, когда разработчики OpenBSD, позиционирующие свою ОС как "самую безопасную", до сих пор не могут реализовать мандатный контроль доступа.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от Аноним (??) on 25-Июл-11, 19:35
	Шифрованные ФС тоже не освоили.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	8. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	–1 +/–
	Сообщение от Аноним (??) on 25-Июл-11, 22:11
	> Шифрованные ФС тоже не освоили. Более того, этот секурный шелл, будучи вывешенным на серваке в датацентре начинает вскоре жрать процессорное время оптом - автоматические брутфорсеры с удовольствием пытаются проверить пароли на секурность. При том нет никаких встроенных средств для автобана хотя-бы наиболее наглых, долбящих десятками потоков с одного айпи. Приходится постоянно городить костыли, защищающие этого "секурного" от наиболее наглых автобрутфорсеров :(.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	9. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+6 +/–
	Сообщение от nbw on 25-Июл-11, 22:30
	> Более того, этот секурный шелл, будучи вывешенным на серваке в датацентре начинает вскоре жрать процессорное время оптом - автоматические брутфорсеры с удовольствием пытаются проверить пароли на секурность. При том нет никаких встроенных средств для автобана хотя-бы наиболее наглых, долбящих десятками потоков с одного айпи. Приходится постоянно городить костыли, защищающие этого "секурного" от наиболее наглых автобрутфорсеров :( Ежели у вас на "серваке в датацентре" ssh висит без всякой защиты да ещё и на стандартном порту, то вы ССЗБ. iptables для кого придумали? Или файрволы нынче не в моде? А если есть файрвол, зачем его функциональность пихать в другие демоны? И не надо "городить костыли" - достаточно написать несколько шаблонов конфигурации, всё равно от этого никуда не деться.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+2 +/–
	Сообщение от ы on 25-Июл-11, 22:53
	> ssh висит ... на стандартном порту, то вы ССЗБ. iptables для кого придумали? плюсую. для совсем же тупых\ленивых есть DenyHosts (http://denyhosts.sourceforge.net/) итп.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	14. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+3 +/–
	Сообщение от Анонимко on 25-Июл-11, 23:26
	А так же fail2ban.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	39. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от r on 26-Июл-11, 15:23
	pf!! :))) встроено
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	19. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от Аноним (??) on 26-Июл-11, 00:06
	Пытаться засунуть в сервер удаленного доступа IDS/IPS - не юниксвейно. Может, туда еще танцующих свинок запихнуть? Юниксвейно - юзать его в связке со специализированной IDS/IPS, например fail2ban. Настраивается легко и быстро.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	50. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от Клыкастый (ok) on 27-Июл-11, 05:11
	> Может, туда еще танцующих свинок запихнуть? да! да! а можно? :)
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	22. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+1 +/–
	Сообщение от nuclight (ok) on 26-Июл-11, 02:04
	>> Шифрованные ФС тоже не освоили. > Более того, этот секурный шелл, будучи вывешенным на серваке в датацентре начинает > вскоре жрать процессорное время оптом - автоматические брутфорсеры с удовольствием пытаются > проверить пароли на секурность. При том нет никаких встроенных средств для > автобана хотя-бы наиболее наглых, долбящих десятками потоков с одного айпи. Приходится > постоянно городить костыли, защищающие этого "секурного" от наиболее наглых автобрутфорсеров > :(. 294, да залогинься уже
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	24. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от 1 (??) on 26-Июл-11, 04:49
	он пароль потерял, уже полгода не ходит под своим логином
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	16. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от yason on 25-Июл-11, 23:57
	Кто вам это сказал? Почитайте man softraid. Хотя бы на сайте проекта, т.к. виртуалку вы врядли будете поднимать, а больше вам посмотреть негде, как я понимаю.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	20. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от Аноним (??) on 26-Июл-11, 00:11
	>>Шифрованные ФС >man softraid А про программные рейды, видимо, придется смотреть в man cryptofs? :)
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	43. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от yason on 26-Июл-11, 16:40
	Судя по всему писать вы любите больше, чем читать. Ну удачи. Может все мы доживём до появления вашего опуса по шифрованию ФС в OpenBSD.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	26. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Июл-11, 07:21
	> Шифрованные ФС тоже не освоили. В OpenBSD шифруют не ФС, а диски. См. vnd(4) и softraid(4).
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	33. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от ананим on 26-Июл-11, 11:47
	а у линуха и так, и так и разэдак: http://www.nixp.ru/articles/%D0%A8%D0%B8... но речь про шифрование фс.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	35. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от Аноним (??) on 26-Июл-11, 12:05
	ох уж эти пальцезагибатели
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	37. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от ананим on 26-Июл-11, 13:38
	ой, да бросьте уже. большой выбор проверенных решений никому и никогда не мешал. тем более что шифровать всё блочное устройство - это весьма на любителя. я уже молчу про аппаратную шифрацию типа http://ru.wikipedia.org/wiki/%D0%90%D0%B... и это http://ru.wikipedia.org/wiki/EToken
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	42. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Июл-11, 15:57
	> а у линуха и так, и так и разэдак: > http://www.nixp.ru/articles/%D0%A8%D0%B8... > но речь про шифрование фс. Шифрование блочного устройства проще и надёжнее, вот и всё. А через vnd(4) вы можете поиметь псевдодиск из любого обычного файла — по сути, придёте к тому же. Вы ФС зачем шифруете? Чтобы враг, если что, не прочёл, так? Через шифрование диска вы добьётесь того же самого. В чём для вас принципиальна разница?
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	23. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+1 +/–
	Сообщение от 1 (??) on 26-Июл-11, 04:48
	> не могут откуда дровишки?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	27. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Июл-11, 07:49
	>>Но у пингвинов есть куда более мощный и гибкий SELinux, и система ограничений основных серверных демонов (а не только sshd) там существует уже давно. > И это в то время, когда разработчики OpenBSD, позиционирующие свою ОС как > "самую безопасную", до сих пор не могут реализовать мандатный контроль доступа. Не «не могут», а «не собираются». Листать через «next in thread»: http://marc.info/?l=openbsd-misc&m=126412951221902&w=2 Не путайте безопасность и фичастость.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	34. "Невроз OpenBSD"	+/–
	Сообщение от nuclight (ok) on 26-Июл-11, 11:56
	>>>Но у пингвинов есть куда более мощный и гибкий SELinux, и система ограничений основных серверных демонов (а не только sshd) там существует уже давно. >> И это в то время, когда разработчики OpenBSD, позиционирующие свою ОС как >> "самую безопасную", до сих пор не могут реализовать мандатный контроль доступа. > Не «не могут», а «не собираются». Листать через «next in thread»: > http://marc.info/?l=openbsd-misc&m=126412951221902&w=2 > Не путайте безопасность и фичастость. Безопасность - не сущность, а атрибут. Первично решение задач, фокус может быть на безопасности способа её решения, но не отказе от решения как такового во имя некоей "безопасности". Какая ОС безопаснее? Та, где больше, например, способов решения задач, обладающих атрибутом безопасности. Таким образом, как бы ни парадоксально звучало, отказываясь от безопасных способов решения ряда задач, типа того же мандатного контроля, "самая безопасная" ОС OpenBSD начинает проигрывать другим в области безопасности же.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	41. "Невроз OpenBSD"	–1 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Июл-11, 15:53
	> Какая ОС безопаснее? Та, где больше, > например, способов решения задач, обладающих атрибутом безопасности. Ну бред же. :) Вот в той же Windows NT всякие ACL и MAC имеются с рождения. И даже используются везде и повсюду, в отличие от всяких там grsecurity. Что, Windows NT от этого становится безопаснее? :) От количества способов безопасность сама по себе не улучшится. Можно говорить «вероятнее, там, где больше способов, будет лучше реализация», но не более того. И ещё, не стоит забывать, что каждая система защита тоже может быть уязвима. Поэтому, как ни парадоксально, чем больше систем защиты, тем потенциально уязвимее ОС. Системы защиты должны быть — да. Но в меру: их должно быть мало, они должны быть просты и эффективны в работе. MAC с этой точки зрения весьма и весьма неоднозначен, так как вероятность ошибки администратора или программиста возрастает многократно. При этом ложное чувство защищённости зачастую провоцирует пренебрежение другими системами защиты (только не говорите, что «это неправильные админы» — покажите мне человека, который никогда и ничем не пренебрегает), и в конечном счёте зачастую приводит к появлению дыр в защите — которых просто не было бы без этих систем защиты. И на всякий случай: речь не о том, что MAC — это однозначно плохо. Речь о том, что его недостатки зачастую недооценивают. А если кто-то придумает грамотное развитие идеи MAC, нивелирующее его недостатки, то patches are always welcome. :)
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	44. "Невроз OpenBSD"	+/–
	Сообщение от nuclight (ok) on 26-Июл-11, 17:16
	>> Какая ОС безопаснее? Та, где больше, >> например, способов решения задач, обладающих атрибутом безопасности. > Ну бред же. :) Ничуть. Что, есть какой-то иной способ сравнивать безопасность _инструментов_ ? А ОС как то, на что может влиять коллектив её авторов, суть инструмент. Вот на пальцах: были опасные бритвы, щас повсеместно в ходу безопасные (станки). Можно порезаться и безопасной, можно умело выбриться и опасной - однако название-то у них неспроста, а? > Вот в той же Windows NT всякие ACL > и MAC имеются с рождения. И даже используются везде и повсюду, > в отличие от всяких там grsecurity. Что, Windows NT от этого > становится безопаснее? :) Дык в сочетании смотреть надо. При прочих равных - да, безопаснее. > От количества способов безопасность сама по себе не улучшится. Можно говорить «вероятнее, > там, где больше способов, будет лучше реализация», но не более того. Пфф. В реальном мире любая безопасность - описывается лишь вероятностью. Поэтому уравнение простое: больше безопасных способов значит меньше небезопасных, т.е. меньше вероятность нарушения безопасности. > И ещё, не стоит забывать, что каждая система защита тоже может быть > уязвима. Поэтому, как ни парадоксально, чем больше систем защиты, тем потенциально > уязвимее ОС. Это демагогия разряда "чем больше я учу, тем больше знаю, чем больше знаю, тем больше забываю, чем больше забываю - тем меньше знаю, тогда зачем учиться?". Я б потребовал вести дискуссию корректно, но, к сожалению, у вас там всех эти противоречия даже не осознаются, тут лечение у психолога нужно... >[оверквотинг удален] > как вероятность ошибки администратора или программиста возрастает многократно. При этом > ложное чувство защищённости зачастую провоцирует пренебрежение другими системами защиты > (только не говорите, что «это неправильные админы» — покажите мне человека, > который никогда и ничем не пренебрегает), и в конечном счёте зачастую > приводит к появлению дыр в защите — которых просто не было > бы без этих систем защиты. > И на всякий случай: речь не о том, что MAC — это > однозначно плохо. Речь о том, что его недостатки зачастую недооценивают. > А если кто-то придумает грамотное развитие идеи MAC, нивелирующее его недостатки, то > patches are always welcome. :) И вот это всё - тоже продолжение той же демагогии, выраженной сабжем. Это как если бы с бритвами было, нашли у станков недостатки, и OpenBSD предложило бы всем вообще не бриться и отпускать бороду. Т.е. отказывается от решения задачи вообще, вместо поиска безопасного способа. Поиск отмазки вместо поиска решения. Админы неправильные? Ну так напишите большими красными буквами, что в этой подсистеме легко ошибиться и иметь ложное чувство безопасности, так что следует пойти изучать. Делайте то, на что можете повлиять, остальное уже не проблемы инструмента. Я ведь не зря сказал, что первично решение задач, а безопасность лишь атрибут - эта ключевая мысль из квоты "почему-то" выкинута. Если есть система, которая решает 3 задачи 5-ю безопасными способами, и есть система, которая решает 10 задач 4-мя, выберут вторую, потому что первая банально не позволяет решить их совсем. Ну и кому от этого стало лучше, а?.. И даже система, которая позволит решить 10 задач 8-ю безопасными способами, будет лучше и безопаснее той системы для 3 задач, хотя в процентном соотношении она, казалось бы, хуже.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	45. "Невроз OpenBSD"	+1 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Июл-11, 17:39
	>>> Какая ОС безопаснее? Та, где больше, >>> например, способов решения задач, обладающих атрибутом безопасности. >> Ну бред же. :) > Ничуть. Что, есть какой-то иной способ сравнивать безопасность _инструментов_ ? А ОС > как то, на что может влиять коллектив её авторов, суть инструмент. Вообще-то, есть. Можно сравнить вот так: этот инструмент удобнее держать, а этот может работать в условиях Крайнего Севера и поэтому для полярников выбор очевиден. И т.д. > Вот на пальцах: были опасные бритвы, щас повсеместно в ходу безопасные (станки). > Можно порезаться и безопасной, можно умело выбриться и опасной - однако > название-то у них неспроста, а? Вы берёте только ОДИН параметр (количество механизмов, теоретически могущих повысить безопасность) и закрываете глаза на всё остальное. Потом тут же говорите, что не закрываете. Нельзя рассматривать эти явления отдельно, они взаимосвязаны. Чем проще конечная система, тем она безопаснее — с этим вы будете спорить? >> Вот в той же Windows NT всякие ACL >> и MAC имеются с рождения. И даже используются везде и повсюду, >> в отличие от всяких там grsecurity. Что, Windows NT от этого >> становится безопаснее? :) > Дык в сочетании смотреть надо. При прочих равных - да, безопаснее. Нет. Но, видимо, моих скромных усилий недостаточно, чтобы это донести. :( >> От количества способов безопасность сама по себе не улучшится. Можно говорить «вероятнее, >> там, где больше способов, будет лучше реализация», но не более того. > Пфф. В реальном мире любая безопасность - описывается лишь вероятностью. Поэтому уравнение > простое: больше безопасных способов значит меньше небезопасных, т.е. меньше вероятность > нарушения безопасности. Стоп-стоп-стоп. Из наличия способа улучшения безопасности не обязательно вытекает улучшение безопасности! Этот способ ещё должен: а) не содержать явных проблем с собственной реализацией; б) не иметь побочных последствий; в) постоянно использоваться; г) не быть отключаемым; д) ... >> И ещё, не стоит забывать, что каждая система защита тоже может быть >> уязвима. Поэтому, как ни парадоксально, чем больше систем защиты, тем потенциально >> уязвимее ОС. > Это демагогия разряда "чем больше я учу, тем больше знаю, чем больше > знаю, тем больше забываю, чем больше забываю - тем меньше знаю, > тогда зачем учиться?". Я б потребовал вести дискуссию корректно, но, к > сожалению, у вас там всех эти противоречия даже не осознаются, тут > лечение у психолога нужно... Опять вы на личности переходите. Не видя бревна в собственном глазу. >[оверквотинг удален] >> бы без этих систем защиты. >> И на всякий случай: речь не о том, что MAC — это >> однозначно плохо. Речь о том, что его недостатки зачастую недооценивают. >> А если кто-то придумает грамотное развитие идеи MAC, нивелирующее его недостатки, то >> patches are always welcome. :) > И вот это всё - тоже продолжение той же демагогии, выраженной сабжем. > Это как если бы с бритвами было, нашли у станков недостатки, > и OpenBSD предложило бы всем вообще не бриться и отпускать бороду. > Т.е. отказывается от решения задачи вообще, вместо поиска безопасного способа. Поиск > отмазки вместо поиска решения. Можете так считать, ваше право. Вообще давно известно, что OpenBSD-шники — стадо мастурбирующих обезъян. ;) > Админы неправильные? Ну так напишите большими красными буквами, что в этой подсистеме > легко ошибиться и иметь ложное чувство безопасности, так что следует пойти > изучать. Делайте то, на что можете повлиять, остальное уже не проблемы > инструмента. > Я ведь не зря сказал, что первично решение задач, а безопасность лишь > атрибут - эта ключевая мысль из квоты "почему-то" выкинута. Если есть > система, которая решает 3 задачи 5-ю безопасными способами, и есть система, > которая решает 10 задач 4-мя, выберут вторую, потому что первая банально > не позволяет решить их совсем. Ну и кому от этого стало > лучше, а?.. Повторюсь, вы переоцениваете MAC. Реальные задачи, которые решаются посредством него, решаются и без него. Ну а синтетические случаи — для синтетических людей, живущих в синтетическом мире. > И даже система, которая позволит решить 10 задач 8-ю безопасными способами, будет > лучше и безопаснее той системы для 3 задач, хотя в процентном > соотношении она, казалось бы, хуже. Вы меня не слышите. Вам говорят, что те самые «безопасные способы» вносят новые риски, а вы не слышите, уверяя, что всё равно лучше всё усложнить, и это будет безопаснее. Боюсь, дискуссия бесполезна, я из неё выхожу.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	47. "Невроз OpenBSD"	–3 +/–
	Сообщение от nuclight (ok) on 26-Июл-11, 19:32
	>>>> Какая ОС безопаснее? Та, где больше, >>>> например, способов решения задач, обладающих атрибутом безопасности. >>> Ну бред же. :) >> Ничуть. Что, есть какой-то иной способ сравнивать безопасность _инструментов_ ? А ОС >> как то, на что может влиять коллектив её авторов, суть инструмент. > Вообще-то, есть. Можно сравнить вот так: этот инструмент удобнее держать, а этот > может работать в условиях Крайнего Севера и поэтому для полярников выбор > очевиден. И т.д. Чего? Я ж четко сказал - "безопасность инструментов". А не удобство, пригодность к определенным условиям работы, и другие атрибуты. Атрибуты, еще раз подчеркну. Мы тут обсуждаем один из атрибутов - безопасность. Так вот, про собственно безопасность Вы другого метода так и не дали. На другие факторы, необходимые для достижения цели, перескакивать не надо, у нас не об этом дискуссия. >> Вот на пальцах: были опасные бритвы, щас повсеместно в ходу безопасные (станки). >> Можно порезаться и безопасной, можно умело выбриться и опасной - однако >> название-то у них неспроста, а? > Вы берёте только ОДИН параметр (количество механизмов, > теоретически могущих повысить безопасность) > и закрываете глаза на всё остальное. Чо? Не надо подменять понятия. Я беру в общем, с высоты птичьего полета - вот эти способы обладают свойством безопасности, а вон те - нет. Они такие в этом рассмотрении уже по определению. А каким именно способом достигается свойство безопасности, какие там параметры - это уже _детали_, которые возникают при рассмотрении более крупным планом. Не смешивайте два разных поля. Про эти детали я говорю дальше. > Потом тут же говорите, что не закрываете. > Нельзя рассматривать эти явления отдельно, они взаимосвязаны. Вы ниже прочитайте, я именно об этом говорил, в (1). > Чем проще конечная система, тем она безопаснее — с этим вы будете спорить? Разумеется, с этим никто не спорит. Поинт в том, что простые конечные системы не справляются с реальными практическими задачами. Я ведь о чем толкую - о том, что первично решение задачи. Безопасность не то что имеет меньший приоритет и менее ценна, чем решение - она вообще смысла не имеет, если задача не решается. Потому что она не сущность, а всего лишь свойство сущности. >>> Вот в той же Windows NT всякие ACL и MAC имеются с рождения. >>>  И даже используются везде и повсюду, в отличие от всяких там grsecurity. >>>  Что, Windows NT от этого становится безопаснее? :) >> Дык в сочетании смотреть надо. При прочих равных - да, безопаснее. ^^^^^^^^ (1) > Нет. Но, видимо, моих скромных усилий недостаточно, чтобы это донести. :( Я определение ввёл? Ввёл (о том, что есть безопасность и как сравнить в общем). Граничные условия поставил? Поставил (при прочих равных). У меня всё четко и логично вытекает. От Вас опровергающих аргументов не было. >>> От количества способов безопасность сама по себе не улучшится. Можно говорить «вероятнее, >>> там, где больше способов, будет лучше реализация», но не более того. >> Пфф. В реальном мире любая безопасность - описывается лишь вероятностью. Поэтому уравнение >> простое: больше безопасных способов значит меньше небезопасных, т.е. меньше вероятность >> нарушения безопасности. > Стоп-стоп-стоп. Из наличия способа улучшения безопасности не обязательно вытекает улучшение > безопасности! Никакой не "стоп", Вы опять подменяете понятия. Я говорил о чем? О "способах решать задачу безопасно". Т.е. уже имеющемся по определению способе. А Вы передергиваете на "способы улучшения безопасности", которыми финальный "способ решить задачу" должен быть достигнут. То есть дробите на подзадачи, и подменяете целое частным - такой подзадачей. > Этот способ ещё должен: а) не содержать явных проблем с > собственной реализацией; б) не иметь побочных последствий; в) постоянно использоваться; > г) не быть отключаемым; д) ... Это всё станет актуальным тогда, когда инженер, которому поручена подзадача обеспечения безопасности решения общей задачи, станет эту самую подзадачу решать. Если сама главная задача (цель), по его заявлениям, не должна решаться из-за невозможности обеспечить безопасность - его уволят и найдут более грамотного, который эту безопасность таки сможет обеспечить. Дык вот, OpenBSD можно сравнить с тем инженером, который говорит, что не будет решать задачу. То есть который не нужен. >>> И ещё, не стоит забывать, что каждая система защита тоже может быть >>> уязвима. Поэтому, как ни парадоксально, чем больше систем защиты, тем потенциально >>> уязвимее ОС. >> Это демагогия разряда "чем больше я учу, тем больше знаю, чем больше >> знаю, тем больше забываю, чем больше забываю - тем меньше знаю, >> тогда зачем учиться?". Я б потребовал вести дискуссию корректно, но, к >> сожалению, у вас там всех эти противоречия даже не осознаются, тут >> лечение у психолога нужно... > Опять вы на личности переходите. Не видя бревна в собственном глазу. Это, конечно, очень мило, объявить про бревно в собственном глазу, не называя при этом собственно бревна. При том, что болезнь - это, вообще-то, послабление. Без поблажее я бы за демагогию имел право потребовать куда строже. Канделябром по рукам бить, например. >>> однозначно плохо. Речь о том, что его недостатки зачастую недооценивают. >>> А если кто-то придумает грамотное развитие идеи MAC, нивелирующее его недостатки, то >>> patches are always welcome. :) >> И вот это всё - тоже продолжение той же демагогии, выраженной сабжем. >> Это как если бы с бритвами было, нашли у станков недостатки, >> и OpenBSD предложило бы всем вообще не бриться и отпускать бороду. >> Т.е. отказывается от решения задачи вообще, вместо поиска безопасного способа. Поиск >> отмазки вместо поиска решения. > Можете так считать, ваше право. Вообще давно известно, что OpenBSD-шники — стадо > мастурбирующих обезъян. ;) Видите ли, это не просто "мое мнение", а действительно так. "Можете так считать, ваше право" как бы оставляет за вами право думать иначе, но на самом деле у вас такого права нет, потому как оно объективно неправильное. >> которая решает 10 задач 4-мя, выберут вторую, потому что первая банально >> не позволяет решить их совсем. Ну и кому от этого стало >> лучше, а?.. > Повторюсь, вы переоцениваете MAC. Реальные задачи, которые решаются посредством него, > решаются и без него. Ну а синтетические случаи — для синтетических > людей, живущих в синтетическом мире. Мне на самом деле довольно пофиг, чего там переоценивается или недооценивается - меня интересуют истоки мышления и их последствия. На этом уровне рассмотрения проблемы конкретной посистемы неважны. Хотя я вообще-то и решал с помощью ACL реальные задачи, нерешаемые традиционной моделью прав Unix. >> И даже система, которая позволит решить 10 задач 8-ю безопасными способами, будет >> лучше и безопаснее той системы для 3 задач, хотя в процентном >> соотношении она, казалось бы, хуже. > Вы меня не слышите. Вам говорят, что те самые «безопасные способы» вносят > новые риски, а вы не слышите, уверяя, что всё равно лучше > всё усложнить, и это будет безопаснее. > Боюсь, дискуссия бесполезна, я из неё выхожу. Нет, Вы просто нифига не понимаете, о чем речь, и проецируете свое неслышание на меня. Я-то с защитными механизмами психики знаком уж несколько лет на практике, суровой практике. И мне прекрасно видно и понятно Ваше желание немедленно сбежать из дискуссии, как только приперли к стенке железными аргументами. Слишком уж близко к болезненному открытию глаз на реальность ;)
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	49. "Невроз OpenBSD"	+/–
	Сообщение от mixac on 26-Июл-11, 23:22
	ох уж эти безопасники придут, психологией задавят "вумными" словами с панталыку собьют.. впарят свою супер-пупер систему ген директору... А на деле потом окажется что все равно = порты закрыть провода отрезать печати охрана прослушка подписка о не разглашении и старые дедовские способы от паяльно-ректального метода -не знаешь не выдашь )
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	52. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от Аноним (??) on 27-Июл-11, 14:08
	> Не «не могут», а «не собираются». Листать через «next in thread»: Все как обычно. "Если у нас чего-то нет, значит, нам это не нужно" А объяснить, почему именно не нужно - дело штатных демагогов. Вот не люблю я, когда вместо программистов работают демагоги. > Не путайте безопасность и фичастость. MAC - это безопасность. А то, что в сабже - костыли от неимения MAC. Никогда еще не видел, чтобы нагромождение костылей с закономерным запутыванием всего и вся повышало безопасность.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	55. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 27-Июл-11, 14:52
	>> Не «не могут», а «не собираются». Листать через «next in thread»: > Все как обычно. "Если у нас чего-то нет, значит, нам это не > нужно" > А объяснить, почему именно не нужно - дело штатных демагогов. Если быть более точным, текущие реализации MAC опёнковцев не особо устраивают. Видел комментарии от разработчиков о возможности прикручивания ACL к файловой системе. В целом же классический UNIX-контроль доступа звучит как: «это твоя сфера ответственности и делай здесь, что тебе нужно, а это не твоя», а MAC — «вот это можно, вот это нельзя, здесь можно только это, за исключением ещё вот того и того...». И единственно правильного выбора здесь нет. :) > Вот не люблю я, когда вместо программистов работают демагоги. Плодами трудов этих демагогов почему-то пользуются люди далеко за пределами OpenBSD. ;) >> Не путайте безопасность и фичастость. > MAC - это безопасность. MAC — это способ раздачи и ограничения прав доступа. Один из. > А то, что в сабже - костыли от неимения MAC. Кому костыли, а кому и нет. Потенциал у systrace вообще довольно большой. > Никогда еще не видел, чтобы нагромождение костылей с закономерным запутыванием всего и > вся повышало безопасность. Это вы про MAC, да? ;)
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	46. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от Аноним (??) on 26-Июл-11, 18:47
	Вообще-то мандантный. И вообще-то реализовали.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	48. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Июл-11, 21:12
	> Вообще-то мандантный. И вообще-то реализовали. По русскому — двойка, по архитектуре OpenBSD — тоже.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	7. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+1 +/–
	Сообщение от Аноним (??) on 25-Июл-11, 22:04
	> Насколько я знаю, в Linux абсолютно точно такой же технологии - нет. > Поэтому на портирование данной конкретной фичи за пределы OpenBSD рассчитывать не > стоит. Там для ограничений и постановки в загон есть куда как более крутой cgroups и ряд очень вкусных флагов у сискола clone() который в конечном итоге и стартует на самом деле процессы. Можно буквально одним сисколом загнать процесс в персональное стойло, откуда он не вылезет в остальную систему нифига. Очень удобно и не надо геморроиться с мандатным контролем доступа.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	11. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от Аноним (??) on 25-Июл-11, 23:10
	Да, cgroups и namespaces - это реально круто, можно городить джейлы с гибким ограничением по лимитам. Но это типично линуксовые фичи, никак не оговоренные в POSIX и не имеющие аналогов в BSD и UNIX. Поэтому здесь мы сталкиваемся с "проблемой systemd" - чтобы сделать что-либо реально крутое, нужно сосредоточиться именно на линуксе, не пытаясь тянуть совместимость с отстающими в развитии платформами.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	12. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+1 +/–
	Сообщение от ы on 25-Июл-11, 23:18
	> сосредоточиться именно на линуксе, не пытаясь > тянуть совместимость с отстающими в развитии вы так пишите, как будто это что-то плохое.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	13. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от Аноним (??) on 25-Июл-11, 23:22
	Для многих разработчиков это неприемлемо, в основном из-за стереотипности мышления.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	30. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от ананим on 26-Июл-11, 11:37
	да глупости всё это. все никсы всегда отличались - посикс+что-то_своё. и всегда серьёзные проекты поддерживали все специфичные фичи каждой будь то doors в соляре и ещё что. а opennssh - вполне себе серьёзный проект. Зы кстати, тут всегда про бсд говорят, дескать это у них был, а линух позаимствовал. Вот интересный факт: >lsh            Niels Möller            Active    1999-05-23 [2] >OpenSSH    The OpenBSD project    Active    1999-12-01 http://en.wikipedia.org/wiki/Comparison_of_SSH_servers
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	36. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от xz (??) on 26-Июл-11, 13:23
	>>lsh            Niels Möller            Active    1999-05-23 [2] >>OpenSSH    The OpenBSD project    Active    1999-12-01 >http://en.wikipedia.org/wiki/Comparison_of_SSH_servers ахаха. почитайте внимательно как появился на свет OpenSSH. если коротко - была такая финская компания SSH Communications Security (сейчас они называются Tectia - http://www.tectia.com). так вот OpenSSH появился как форк ssh-сервера компании SSH Communications Security, ибо после релиза 1.2.12 SSH Communications Security закрыла код своего продукта.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	38. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от ананим on 26-Июл-11, 13:43
	да хоть ухаха. факт остается фактом - сам проект OpenSSH  - The OpenBSD project    Active    1999-12-01 что позже гпл-ного варианта.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	40. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от xz (??) on 26-Июл-11, 15:47
	GPL головного мозга?
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	56. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от ананим on 27-Июл-11, 21:07
	да хрен тебя рязбёрет, что там у тебя.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	58. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от Аноним (??) on 29-Июл-11, 07:55
	Только что-то не нужен никому этот GPL-ный вариант...
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	15. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от Аноним (??) on 25-Июл-11, 23:32
	> не пытаясь тянуть совместимость с отстающими в развитии платформами. А почему вы _другую_ реализацию называете отстающей? На основании какой причины? Просто потому что она - другая? Это глупо.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	17. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от Аноним (??) on 25-Июл-11, 23:59
	>А почему вы _другую_ реализацию называете отстающей? На основании какой причины? Просто потому что она - другая? Это глупо. Отстающими были названы не другие реализации существующих технологий, а платформы, не имеющие технологий, сравнимых по возможностям с cgroups и namespaces.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	18. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от Аноним (??) on 26-Июл-11, 00:01
	> А почему вы _другую_ реализацию называете отстающей? На основании какой причины? Просто > потому что она - другая? Это глупо. Иметь другую реализацию технологии (схожую по возможностям) и не иметь вообще никакой реализации - это два принципиально разных случая. В данном случае речь идет именно о втором.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	21. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от nuclight (ok) on 26-Июл-11, 02:03
	>> А почему вы _другую_ реализацию называете отстающей? На основании какой причины? Просто >> потому что она - другая? Это глупо. > Иметь другую реализацию технологии (схожую по возможностям) и не иметь вообще никакой > реализации - это два принципиально разных случая. В данном случае речь > идет именно о втором. И будет этот второй случай враньем, проистекающим от незнания других систем.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	31. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от ананим on 26-Июл-11, 11:39
	не будет. потому что сейчас конкретно речь идёт об опенбсд.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	51. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от Аноним (??) on 27-Июл-11, 14:02
	>И будет этот второй случай враньем, проистекающим от незнания других систем. Вы так говорите, как будто можете действительно назвать технологии аналогичного уровня в других системах, а не заниматься демагогией.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	53. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от nuclight (ok) on 27-Июл-11, 14:12
	>>И будет этот второй случай враньем, проистекающим от незнания других систем. > Вы так говорите, как будто можете действительно назвать технологии аналогичного уровня > в других системах, а не заниматься демагогией. Вы так говорите, как будто не будет тут же анонимной демагогии, что солярку тут не рассматривают, и ваще. Вон, в соседнем треде уже наглядный пример.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	57. "Для OpenSSH реализована поддержка изоляции на этапе до начал..."	+/–
	Сообщение от ананим on 27-Июл-11, 21:09
	дык и нечего соляркой махать. В рамках сабжа это вообще офтопик, а не в рамках - у соляры тоже масса своих ограничений.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

29. "Для OpenSSH реализована поддержка дополнительной изоляции"	+/–
Сообщение от kibab on 26-Июл-11, 10:14
Вот в ту "заглушку" наверняка хорошо воткнётся Capsicum во FreeBSD.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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