 fox
II/IDEC networks :: txt.drafts.14 :: / черновик от тэо
|
Login |
[#]
черновик от тэо
51t(lenina,1) — All
2014-07-26 14:30:23
Re: g2k14: Theo de Raadt: безопасность и конфигурашность
Лидер проекта OpenBSD Тео де Раадт (deraadt@) пишет об g2k14:
Две недели до Словении я работал с Бобом Беком над заменой функциям, которые потребуются для эмуляции getentropy(2). С начала хакафона пошёл окончательный этап работы, чтобы гарантировать, что у Боба и Брента Кука - всё путём.
Затем пришло время конкретно разобраться с одним вопросом касаемо безопасности, о котором я узнал. Истощение дескрипторов может использоваться для сокрытия отчётов о переполнении буфера через stack protector. Охрана stack protector требует файловый дескриптор для того, чтобы сообщить об ошибке. Кто-то из тех, кто подписан на блоги по arc4random и getentropy понимают, в чём проблема. *
Эта проблема была сделана очевидной из-за метода песочницы systrace, используемого теперь в ssh инструментах. который препятствует тому, чтобы syslog_r открывал сокет, соединялся, отправлял.. хорошие системные вызовы для того, чтобы сообщить о неудачах, но, однако, опасные - и точно те, что песочница пытается предотвратить.
Проблема была решена созданием нового системного вызова, который может отправлять сообщения для syslogd, вообще не используя никаких дополнительных ресурсов: syslog_r(3) может это делать напрямую, как по взмаху волшебной палочки. Системный вызов довольно узкоцелевой, поэтому назван sendsyslog(2), but this also fits the narrow use case it will have such as sandboxing.
Это подобно пути getentropy(2), который вырезали из sysctl. Забавно, как одна вещь приводит к другой.
Отдохнув от ядрёной части, самое время взяться за очистку и улучшение для /etc, sysmerge и скриптов установки. Роберт и Антошка помогли нам с планом конкретной зачистки /etc/rc, но это дело ещё не завершено. Оно приведёт к улучшениям в работе sysmerge. Также я работал с пацанами и из отдела инсталляционного скриптования и из отдела DRM, для того, чтобы установщик мог автоматически выставлять aperture.
В остаток хакафона я мелькал тут и там, как обычно, участвуя в проектах других разработчиков. Очень приятная и производительная неделя!
> * Речь об исчерпании лимита на количество открытых файлов, которое в случае использования syslog(3) могло привести к тому, что сообщения об ошибках не попадут в системный журнал. Дело в том, что syslog(3) оперировал через открытие файла /dev/log, которое, в случае исчерпания оных лимитов, становится невозможным.
51t(lenina,1) — All
2014-07-26 14:30:23
Re: g2k14: Theo de Raadt: безопасность и конфигурашность
Лидер проекта OpenBSD Тео де Раадт (deraadt@) пишет об g2k14:
Две недели до Словении я работал с Бобом Беком над заменой функциям, которые потребуются для эмуляции getentropy(2). С начала хакафона пошёл окончательный этап работы, чтобы гарантировать, что у Боба и Брента Кука - всё путём.
Затем пришло время конкретно разобраться с одним вопросом касаемо безопасности, о котором я узнал. Истощение дескрипторов может использоваться для сокрытия отчётов о переполнении буфера через stack protector. Охрана stack protector требует файловый дескриптор для того, чтобы сообщить об ошибке. Кто-то из тех, кто подписан на блоги по arc4random и getentropy понимают, в чём проблема. *
Эта проблема была сделана очевидной из-за метода песочницы systrace, используемого теперь в ssh инструментах. который препятствует тому, чтобы syslog_r открывал сокет, соединялся, отправлял.. хорошие системные вызовы для того, чтобы сообщить о неудачах, но, однако, опасные - и точно те, что песочница пытается предотвратить.
Проблема была решена созданием нового системного вызова, который может отправлять сообщения для syslogd, вообще не используя никаких дополнительных ресурсов: syslog_r(3) может это делать напрямую, как по взмаху волшебной палочки. Системный вызов довольно узкоцелевой, поэтому назван sendsyslog(2), but this also fits the narrow use case it will have such as sandboxing.
Это подобно пути getentropy(2), который вырезали из sysctl. Забавно, как одна вещь приводит к другой.
Отдохнув от ядрёной части, самое время взяться за очистку и улучшение для /etc, sysmerge и скриптов установки. Роберт и Антошка помогли нам с планом конкретной зачистки /etc/rc, но это дело ещё не завершено. Оно приведёт к улучшениям в работе sysmerge. Также я работал с пацанами и из отдела инсталляционного скриптования и из отдела DRM, для того, чтобы установщик мог автоматически выставлять aperture.
В остаток хакафона я мелькал тут и там, как обычно, участвуя в проектах других разработчиков. Очень приятная и производительная неделя!
> * Речь об исчерпании лимита на количество открытых файлов, которое в случае использования syslog(3) могло привести к тому, что сообщения об ошибках не попадут в системный журнал. Дело в том, что syslog(3) оперировал через открытие файла /dev/log, которое, в случае исчерпания оных лимитов, становится невозможным.
[#]
Re: черновик от тэо
zhuk@(lenina,131) — 51t
2014-08-04 19:55:42
(попробовал перевести сам... вроде, терпимо, но надо будет ещё раз вычитать)
g2k14: Theo de Raadt: безопасность и конфигурашность
Лидер проекта OpenBSD Тео де Раадт (deraadt@) пишет об g2k14:
Две недели перед Словенией я работал с Бобом Беком (Bob Beck) над заменяющими getentropy(2) функциями. В начале хакафона были внесены последние штрихи, нужные Бобу и Бренту Куку (Brent Cook) для дальнейшей работы.
Затем пришло время разбираться с очередной проблемой безопасности, о которой мне стало известно. К нашему прискорбию выяснилось, что исчерпание ограничения на количество одновременно открытых файлов может быть использовано для сокрытия уведомлений о переполнении стека от соответствующего механизма защиты. Защитнику стека требуется файловый дескриптор, чтобы сообщить об ошибке. Те, кто уже читал заметки об arc4random и getentropy, уже в курсе данной ситуации.(*)
Проблема стала очевидной из-за технологии "песочницы", используемой ныне в SSH-утилитах, которая закрыла syslog_r() доступ к socket(), connect(), sendto()... всем системным вызовам, необходимым для сообщения об ошибке, но потенциально опасным - что как раз "песочница" и должна предотвращать.
Задача была решена путём создания нового системного вызова, который может отправить сообщение в syslogd без использования лишних ресурсов; syslog_r(3) теперь использует его напрямую: один щелчок, выстрел, поехали дальше. Данный системный вызов имеет более чем узкое применение, и поэтому был назван sendsyslog(2), и при этом он также подходит для специфических условий, таких как использование "песочницы".
В этом плане, ситуация схожа с тем, как getentropy(2) была вынесена из sysctl. Забавно, как одно приводит к другому.
В качестве передышки от пространства ядра, пришла пора для небольшой уборки и, надеюсь, улучшения в /etc, sysmerge и инструментах установки. Роберт и Антуан помогли спланировать практически пустой /etc/rc, эта работа ещё не окончена, но приведёт к улучшенному sysmerge. На других фронтах я работал с теми, кто занимается установочными скриптами и DRM, чтобы в нашем следующем релизе можно было автоматически по возможности прикрывать прямой доступ к оборудованию для X на поддерживаемых в этом плане чипсетах [по сути это современные Intel - прим. ред.].
В остальное время хакафона я мелькал тут и там, как обычно, участвуя в проектах других разработчиков. Очень приятная и производительная неделя!
> * Речь об исчерпании лимита на количество открытых файлов, которое в случае использования syslog(3) могло привести к тому, что сообщения об ошибках не попадут в системный журнал. Дело в том, что syslog(3) оперировал через открытие файла /dev/log, которое, в случае исчерпания оных лимитов, становится невозможным.
zhuk@(lenina,131) — 51t
2014-08-04 19:55:42
(попробовал перевести сам... вроде, терпимо, но надо будет ещё раз вычитать)
g2k14: Theo de Raadt: безопасность и конфигурашность
Лидер проекта OpenBSD Тео де Раадт (deraadt@) пишет об g2k14:
Две недели перед Словенией я работал с Бобом Беком (Bob Beck) над заменяющими getentropy(2) функциями. В начале хакафона были внесены последние штрихи, нужные Бобу и Бренту Куку (Brent Cook) для дальнейшей работы.
Затем пришло время разбираться с очередной проблемой безопасности, о которой мне стало известно. К нашему прискорбию выяснилось, что исчерпание ограничения на количество одновременно открытых файлов может быть использовано для сокрытия уведомлений о переполнении стека от соответствующего механизма защиты. Защитнику стека требуется файловый дескриптор, чтобы сообщить об ошибке. Те, кто уже читал заметки об arc4random и getentropy, уже в курсе данной ситуации.(*)
Проблема стала очевидной из-за технологии "песочницы", используемой ныне в SSH-утилитах, которая закрыла syslog_r() доступ к socket(), connect(), sendto()... всем системным вызовам, необходимым для сообщения об ошибке, но потенциально опасным - что как раз "песочница" и должна предотвращать.
Задача была решена путём создания нового системного вызова, который может отправить сообщение в syslogd без использования лишних ресурсов; syslog_r(3) теперь использует его напрямую: один щелчок, выстрел, поехали дальше. Данный системный вызов имеет более чем узкое применение, и поэтому был назван sendsyslog(2), и при этом он также подходит для специфических условий, таких как использование "песочницы".
В этом плане, ситуация схожа с тем, как getentropy(2) была вынесена из sysctl. Забавно, как одно приводит к другому.
В качестве передышки от пространства ядра, пришла пора для небольшой уборки и, надеюсь, улучшения в /etc, sysmerge и инструментах установки. Роберт и Антуан помогли спланировать практически пустой /etc/rc, эта работа ещё не окончена, но приведёт к улучшенному sysmerge. На других фронтах я работал с теми, кто занимается установочными скриптами и DRM, чтобы в нашем следующем релизе можно было автоматически по возможности прикрывать прямой доступ к оборудованию для X на поддерживаемых в этом плане чипсетах [по сути это современные Intel - прим. ред.].
В остальное время хакафона я мелькал тут и там, как обычно, участвуя в проектах других разработчиков. Очень приятная и производительная неделя!
> * Речь об исчерпании лимита на количество открытых файлов, которое в случае использования syslog(3) могло привести к тому, что сообщения об ошибках не попадут в системный журнал. Дело в том, что syslog(3) оперировал через открытие файла /dev/log, которое, в случае исчерпания оных лимитов, становится невозможным.