Безопасность — Это Проблема Пользовательского Интерфейса



Безопасность — это проблема пользовательского интерфейса.

Говорят, есть очень простой способ обезопасить свой компьютер с Windows — просто выключите его.

За этой шуткой стоит серьезная мысль.

А именно, очень легко создать безопасную систему, если пойти на компромисс с функциональностью.

Машина, которая ничего не делает, очень безопасна по своей природе.

Задача, стоящая перед разработчиками программного обеспечения, заключается в том, как сбалансировать удобство использования и безопасность.



История двух моделей безопасности

Многие утверждают, что UNIX более безопасен, чем Windows. Однако, когда им требуются доказательства, им очень трудно указать на уязвимости в ядре NT. Действительно, на бумаге модель безопасности Windows явно лучше — каждый объект имеет связанный список управления доступом, и этот список проверяется ядром при каждой попытке доступа.

С другой стороны, модель UNIX гораздо более примитивна.

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

Существует всего два уровня безопасности: * Пользователи могут делать все, что им позволяет root * Root может все.

Опыт показывает, что более простая модель обеспечивает большую безопасность, но это не всегда так.

Например, VMS имеет как детальную модель безопасности, так и отличную репутацию в области безопасности.

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

Напротив, большое количество компьютеров с Windows — это домашние машины, которыми управляют люди с небольшими знаниями о компьютере или вообще без них, или в небольших компаниях без ИТ-персонала.

В то время как пользователи VMS тщательно настраивают свои политики безопасности, пользователи Windows просто отключают меры безопасности, поскольку они слишком сложны для правильной настройки.

Возможно, ту же критику можно применить и к UNIX. Чтобы сравнение было справедливым, давайте посмотрим на Mac OS X. Построенная на ядре UNIX (хотя и не особенно традиционном во многих отношениях), OS X наследует модель безопасности UNIX. В OS X система не мешает пользователю в 90% случаев, которые могут ему понадобиться в повседневной деятельности.

Для других действий, таких как установка обновлений, пользователю предлагается ввести пароль.

Другими словами, система безопасности большую часть времени остается вне пути пользователя.



Создаем хорошую систему безопасности

Представьте, что вы хотите построить идеальную систему безопасности.

Первое, что вы можете сделать, это классифицировать все, что программа может делать безопасно.

Этот список может включать запись о личном файле, созданную программой.

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

После сборки системы вы пытаетесь запустить приложение.

Пользователь сразу получает сотни диалоговых окон с сообщениями типа: *Ээта программа только что попыталась подключиться к Интернету.

*Ээта программа только что попыталась получить доступ к этому файлу.

*Ээти программы только что попробовали.

Пользователь нажимает «ОК» во всех этих сообщениях, и программа успешно запускается.

Однако чуть позже появляется другое диалоговое окно с сообщением другого типа: «?Эта программа только что попыталась изменить векторы системных вызовов ядра.

».

Что делает пользователь? Все остальные диалоговые окна учат его, что нажатие кнопки «ОК» заставляет программу работать, поэтому он нажимает «ОК».

О, дорогой, теперь руткит установлен.

Конкретным примером такой системы безопасности является Microsoft ActiveX. Компоненты ActiveX — это простейшие элементы управления COM — динамические библиотеки, поддерживающие понятный интерфейс.

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

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

Результат? Пользователи привыкли нажимать кнопку «ОК» всякий раз, когда ActiveX хочет запуститься, и через этот механизм распространяется значительное количество вредоносных программ.

К сожалению, похоже, что Microsoft извлекла уроки из этой ошибки.

В Windows Vista появилось еще больше всплывающих диалоговых окон, предлагающих пользователю нажать «ОК» в случае любого вопроса, связанного с безопасностью.



SELinux и Systrace

Одной из разработок, получившей много критики, является SELinux, которая добавляет в Linux управление доступом на основе ролей.

С тех пор как SELinux впервые появился в составе Fedora Core, я видел много обращений в службу поддержки примерно такого содержания: Пользователь: «Что-то не работает на моем компьютере с Fedora!» Поддержка: «Попробуйте отключить SELinux» Пользователь: «О! Теперь все работает, спасибо!» В этой ситуации правильным действием для пользователя будет выяснить, почему конкретное приложение не работает с включенным SELinux, изменить соответствующую применяемую политику (или исправить код), а затем снова включить SELinux. Однако этот шаг обычно игнорируется.

Механизм Systrace, присутствующий в OpenBSD и NetBSD, работает в противоположном направлении.

В отличие от SELinux, Systrace должен выполняться на уровне процесса.

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

Несмотря на это преимущество, я подозреваю, что, как и SELinux, Systrace редко используется в тех случаях, когда политика не поставляется вместе с приложением.

Systrace, как и остальная часть философии OpenBSD, когда дело доходит до безопасности, говорит нам одно: люди будут работать над безопасными системами, если их легко защитить.

По умолчанию OpenBSD запускает программы с минимально возможными привилегиями и даже запускает некоторые программы в среде chroot. В целом эти сервисы остаются безопасными, поскольку пользователю не требуется ничего делать для подтверждения своих действий.



Каков ответ?

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

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

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

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

Теги: #перевод #безопасность #ОС #пользовательский интерфейс #Чулан

Вместе с данным постом часто просматривают: