> То, что он сделал, называется «графон» и изучается стилистикой.

1. графоном можно попытаться назвать любой косяк в орфографии. И что с того?

2. так как adriano32, даже сhivы из глухих районах East End'а не пишут. Так что на полноценный графон _это_ слабо походит.

Т.е. по существу не будет? Отлично :}

> 2. так как adriano32, даже сhivы из глухих районах East End'а не пишут.

Англия — всего лишь часть суши, со своим английским.

Зато IPC - дорогая операция. И на примере хрома уже видно, что идея «одна вкладка - один процесс» - дурная. Память жрёт, и таки полного рахделения не вышло, хоть и очень старались (если кто не знает, там после скольки-то вкладок - около 20 AFAIK, несколько вкладок таки обрабатываются одни процессом).

Потом оказывается, что браузер - это не только чтобы веб смотреть, но и локальные HTML5-приложения, которым много чего надо - от проигрывания музыки (и доступа к локальным медиа файлам) до обращения к локальной адресной книге, скажем. Кое-что из этого (та же адресаня книга) на IPC ложится хорошо, а кое-что - не особо.

СОбственно, путь борьбы со взломом браузеров известен: сидеть на дистрибутивной версии, которая, во-первых, бинарно отличается от стандартной, а во-вторых, имеет нормальные security updates вместо мозилло-гугловских игрищ по впихиванию нового фнукционала без спроса.

Вообще, изолированный софт - это полнейшее уродство в плане эргономики, так как удобная и эффективная работа возможно только при хорошей интеграции различных компонентов. И если я не могу по событию в браузере как-то отреагировать - то это баг, который надо исправлять. А безопасностью пусть занимаются те, кому это и положено - маинтайнеры, security team etc.

> Т.е. по существу не будет? Отлично :}

Что еще тебе по существу, солнышко?

> линукс тут последний.

для меня это давно стало аксиомой, ничего странного

странно что всего 57 комментариев в нити. возможно, этому треду не хватает немного оперы или образования в ссср™
что думаете?

> Я уверен, что подавляющая часть разработчиков даже понятия не имеет об этой системе.

Ну блин. Проблема сертификация софта. А кто сказал, что их софт вообще работает правильно?

> пользователь не обязан подтверждать доступ ко _всем_ файлам, необходимым приложению.

Зависит от приложения. Браузеру нужны его файлы (по умолчанию доступны) и те, которые указал пользователь.

> Зато IPC - дорогая операция. И на примере хрома уже видно, что идея «одна вкладка - один процесс» - дурная.

Тут не поспоришь. Нужно найти золотую середину. Но вот отделения орбитра безопасности от приложения делается легко и дешево.

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

Различных, заранее заданных компонентов. Все зависит от правильной настройки политики и работе арбитра, которые дает доступ.

хаха, простите, коллега — слона-то я и не приметил! спасибо.

Да.

> Написание правил - задача разработчика софта

В общем и целом, да. Разработчика. Причём, в последнее время я не сталкивался с тем, в Hardened Gentoo при emerge чего-либо, не устанавливались бы правила для этого самого «чего-либо».

Но дело в том, что иногда приходится переконфигурировать сервер несколько необычным образом. Например, переназначить прослушиваемый порт sshd с 22 на, пусть будет, 5090. Тогда приходится править правила. В софте пользовательского уровня дополнительных требований просто уйма может быть — вплоть до того, что приходится указывать каталоги куда можно, а куда нельзя.

Не совсем так.

> Я уверен, что подавляющая часть разработчиков даже понятия не имеет об этой системе.

Их пишут либо разработчики (действительно), либо мейнтейнеры пакетов в Hardened Gentoo. Всё нормально ставится. Но править... Да. Приходится. Хотя, правила описываются в принципе просто. Просто нужно немного времени потратить чтобы понять их логику работы.

ну я говорил про пользовательский софт. Только разработчик знает, какие привилегии нужны его софту.

для сервера скорей всего нужен шаблон и мануал.

Эммм... Не совсем так.

> Только разработчик знает, какие привилегии нужны его софту.

Тут не только в привилегиях дело. Тут ещё дело в том, как собрана система (что в ней есть и что нужно пользователю). Например, приложение может читать-писать и в файл и в БД. Если разрешить работать только с БД, а пользователю нужно чтобы в файл, то правила придётся подтачивать.

Не спорю, если тот же Апач поднят на 80-м порту и 443 с SSL, то правило по дефолту устроят. Если нет, то придётся помудрить немного. Плюс ещё следовало бы по-хорошему если, то выставить labeling file context для того же веба. Пример того, как это делается для samba и http -> http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/se...

> Зависит от приложения. Браузеру нужны его файлы (по умолчанию

доступны)

Ага, и кто же должен знать, какие файлы ему нужны, чтобы сделать их «по-умолчанию доступными»? Или вы про selinux? Тогда ничего нового.

> возможно, этому треду не хватает немного оперы или образования в ссср™

Скорее, газовых проблем и междугородней... простите, международной политик. А так же либералистичной дерьмократии. И ея переносчиков.

И да! «Выборов»! «Выборов» по-больше добавьте? :)))

ну да. базовые правила подойдут для desctop

для серверов не всегда и базовые сборки подходят

Знает создатель программы

а зачем нужен этот геморрой?

а зачем нужен геморой с разграничением прав ядра и юзерспейса?

>Их пишут либо разработчики (действительно), либо мейнтейнеры пакетов в Hardened Gentoo.

Сколько десктопных приложений есть в Hardened Gentoo ? Я в качестве примера не применимости политик говорил о кде.

Yo, dude, stick ur fucken grammar book in your pooper, mothafucka

Фантазия у вас богатая, но лучше бы вы своим делом занимались.

Не-не-не...

> Сколько десктопных приложений есть в Hardened Gentoo ? Я в качестве примера не применимости политик говорил о кде.

Я выше прямо сказал именно о _серверном_ применении Hardened Gentoo и о том, что можно просто упариться править политики на десктопе. Не для десктопа это всё...

> Yo, dude, stick ur fucken grammar book in your pooper, mothafucka

Спокійно, синку. І так бачу що ти - не москаль.

ну вот мы и достигли взаимопонимания. Я говорил ровно то же самое, но на примере rhel.

Дык! Я и не спорил...

> ну вот мы и достигли взаимопонимания. Я говорил ровно то же самое, но на примере rhel.

Хоть я и апеллировал к Hardened Gentoo, я сразу говорил что это всё не для десктопа. По большому счёту, на десктопе оно и не нужно. На нём достаточно правило чистых рук соблюдать — не тянуть на локалхост незнамо что, незнамо откуда. Не винда, чай...

>Хоть я и апеллировал к Hardened Gentoo, я сразу говорил что это всё не для десктопа.

Видно я пропустил этот момент, и мне пришлось задавать наводящие вопросы ;-)

Это было здесь.

OpenSSH 5.9 с экспериментальным режимом «песочницы» (комментарий)

>> Модули аутентификации, как и раньше, выполняются под root, без всякого sandbox'а.

Добавлю: да, это плохо, но это сложно и/или бессмысленно исправлять:

во-первых, это не совсем точное описание. аутентификация хоть и выполняется от рута, но attack surface - это только протокол коммуникации между привсепнутым чайлдом и главным процессом. код обработки входящих сообщений очень компактен и содержит массу проверок формальной корректности аутентификационного запроса от потомка. данная песочница закрывает возможный attack path, когда злоумышленник подчиняет себе аутентифицирующего чайлда, а потом проводит локальный эксплоит через уязвимость ядра. теперь это практически не возможно (по крайней мере, не OpenBSD, rlimit по-хуже будет, но Дамиен готов включать патчи для других реализаций в портабл версию ссх).
во-вторых, для ограничения родительского процесса следует использовать systrace, или что там в этих ваших линуксах есть аналогичного.

Возможно, мои комментарии выглядели «недовольно» - если так, то это не специально. Я считаю, что OpenSSH написан хорошо, и дополнительное снижение привилегий pre-auth privsep child'а - хорошая новость. Я лишь пояснил о чем именно речь.

это не совсем точное описание.

Упрощенное для нужд нынешней дискуссии. Подробнее здесь:

http://www.citi.umich.edu/u/provos/ssh/privsep.html
http://www.citi.umich.edu/u/provos/papers/privsep.pdf

Еще с тех пор добавилась delayed compression, в результате чего актуальность вынесения сжатия в pre-auth privsep child и передачи состояния zlib дальше (что было непросто в реализации) стала низкой.

аутентификация хоть и выполняется от рута, но attack surface - это только протокол коммуникации между привсепнутым чайлдом и главным процессом. код обработки входящих сообщений очень компактен и содержит массу проверок формальной корректности аутентификационного запроса от потомка.

Что именно считать attack surface - можно обсуждать/спорить. Но реальность такова, что несмотря на все проверки «формальной корректности аутентификационного запроса от потомка» возможны успешные атаки на модули аутентификации. Мы это недавно видели на примере старой FreeBSD с уязвимостью в libopie (которую, кстати, нашли и исправили в FreeBSD лишь в 2010 году). (*) Те примеры успешных remote root атак на libopie были через OpenSSH уже с privsep. Т.е. если уязвимость такая, что ее можно применить через формально корректный запрос (в случае libopie, просто имя пользователя определенной длины), то privsep и проверки не помогают (либо же проверки должны настраиваться на отсев и части формально корректных, но подозрительно выглядящих запросов).

(*) На LOR это была новость про «уязвимость в OpenSSH» на старой FreeBSD. На самом же деле уязвимость была в libopie, подключенном через pam_opie - просто на момент публикации новостей это еще не было исследовано. (Автор exploit'а сам не разбирался как у него так здорово получилось и даже поначалу не поверил, когда Markus ему указал на libopie.) На OpenNet аналогичную новость исправляли по мере поступления новой информации.

данная песочница закрывает возможный attack path, когда злоумышленник подчиняет себе аутентифицирующего чайлда, а потом проводит локальный эксплоит через уязвимость ядра.

Почти так, за исключением слова «аутентифицирующего», да и «закрывает» не до конца (на английском, я бы здесь применил слово mitigates).

теперь это практически не возможно (по крайней мере, не OpenBSD, rlimit по-хуже будет, но Дамиен готов включать патчи для других реализаций в портабл версию ссх).

Да, вероятность успешных атак такого рода стала гораздо ниже.

К тому же, речь шла не только про атаки на ядро, но и про риск использования privsep child'а для исходящих соединений (proxy, DDoS, сканы и т.п.) Эта возможность теперь устранена (вернее, для этого потребуется сначала найти и применить еще одну уязвимость - в родительском процессе, во всё еще доступной части attack surface ядра или в sandbox-механизме).

во-вторых, для ограничения родительского процесса следует использовать systrace, или что там в этих ваших линуксах есть аналогичного.

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