Как стать автором
Обновить

Пришло время переосмыслить безопасность OpenBSD

Время на прочтение6 мин
Количество просмотров8.8K
Всего голосов 21: ↑20 и ↓1+19
Комментарии6

Комментарии 6

OpenBSD считается самой безопасной лишь потому, что она крайне слабо распространена, как следствие, мало кому интересна. Из-за этого в открытом доступе нет уязвимостей для неё (ну или почти нет).
Поэтому говорить, что она безопасна, не совсем правильно. Правильнее говорить, что она не исследована так, как другие. Тогда всё встаёт на свои места и иллюзии растворяются как мираж.

При этом вполне возможно наличие как уязвимостей, так и эксплойтов для этой ОС, использующихся индивидуально либо в узких кругах.

w3techs.com/technologies/details/os-openbsd
Нет, потому что в OpenBSD готовы жертвовать чем угодно ради защищённости.
Пример: отключили HT (hyperthreading) совсем — система стала медленнее на процессорах с HT, но защищённее.
Поэтому говорить, что она безопасна, не совсем правильно.
Правильнее говорить, что она более безопасна.
Системы с закрытым кодом непонятно как исследованы, и непонятно кем. В отличие от систем с открытым кодом.
Статья хорошая. Перевод некоторых частей кривой. Исправляю.

You could look at any of the three components involved… and reasonably conclude that somebody else is doing the checks. Вы можете вызвать каждый из трёх задействованных компонентов… и разумно предположить, что проверку выполняет кто-то другой.


«Вы можете обратить взгляд на каждый из трёх задействованных компонентов… и придти к разумному заключению, что проверку выполняет кто-то другой.»

A request for challenge response auth (think s/key) would return authenticated, instead of silence. Предложение аутентификации запросно-ответного типа (как в системе s/key) возвращает аутентифицированное состояние, а не молчание.


Смысл не искажен, но фраза кривая. И тут лучше было бы переводить would прошедшим временем, поскольку речь идет о неправильном будущем поведении, имевшем место в прошлом (future in the past). Может быть: «Предложение аутентификации запросно-ответного типа (как в системе s/key) возвращало успех аутентификации, а должно было бы не возвращать ничего».

Many years later, the kerberos code was removed, but the refactor to support it remained, and so did the introduced bug. Много лет спустя код kerberos удалили, но часть кода для его поддержки осталась, как и введённая ошибка.


«Много лет спустя код kerberos удалили, но следы рефакторинга для его поддержки остались, как и введённая ошибка.»

Naughty environment variables weren’t removed in ld.so. Из кода ld.so не удалены плохие переменные окружения.


Речь идет не об удалении чего-то из кода, а об удалении переменных окружения при выполнении этого кода. Поэтому: «ld.so не удалял опасные переменные окружения».

ftp would follow redirects to local files. ftp следует редиректам на локальные файлы.


Опять-таки, это лучше переводить прошедшим временем. «ftp следовал редиректам на локальные файлы.»

The NetBSD ftp bug where it would exec redirects is my goto example for runaway features. Баг NetBSD ftp с редиректами — это же давно типичный пример бесконтрольных функций.


Тут речь не о функциях, а о функциональности. Перевод слова «runaway» с помощью слова «бесконтрольные», конечно, корректен, но думаю, что можно было бы поискать синонимы с более подходящей эмоциональной окраской. Как насчет такого варианта: «Баг NetBSD ftp с редиректами — это же давно типичный пример функциональности, вышедшей из-под контроля»? P.S. с синонимом мне помог Google Translate.

So you need to exec a setuid helper to actually deliver to the mbox. Таким образом, чтобы фактически изменить файл mbox, нужно каждый раз запускать вспомогательную функцию setuid.


Речь идет о запуске вспомогательной программы (бинарника на диске), а не функции. Функция не может быть setuid. Поэтому: «Таким образом, чтобы фактически доставить письмо в mbox, нужно каждый раз запускать вспомогательную setuid-программу.»

P.S. Разделы «smtpd from» и выводы переведены на «отлично». Думаю, что переводчику следует сходить на курсы по программированию на Си и по архитектуре операционных систем, тогда и более низкоуровневые темы станут понятны на 100% и поэтому переведутся правильно.
Файловую систему в ней для начала надо переосмыслить. Чтобы её было хотя бы не страшно на боевой сервак поставить и чтобы она не сдохла случайно от внезапной перезагрузки. О какой безопасности может идти речь, если её придётся восстанавливать после банального скачка напряжения.

Такая же проблема с ReactOS. Ни о какой замене Windows, даже там где она способна его заменить нет никакой речи, потому что способна сдохнуть на ровном месте из-за некорректной перезагрузки.
НЛО прилетело и опубликовало эту надпись здесь
Код C не вылетал с ошибкой из-за отсутствия обработки ошибок или потому что ошибка распределения памяти осталась незаметной.
Как сторонник различных систем типизации не могу понять этот абзац. Вообще-то да, именно строгие и выразительные системы типов могут гарантировать отсутствие подобных ошибок. Язык С же не имеет ни строгую, ни выразительную систему типов.


Непонятное предложение надо понимать (это не перевод!) так: «Код в идеале должен был упасть или вообще не скомпилироваться, но он был написан на языке C, где слишком легко не написать обработку ошибок или не заметить ошибку выделения памяти».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий