Безопасность — проблема пользовательского интерфейса.
Говорят, есть очень простой способ обезопасить компьютер с Windows — просто выключить его. За этой шуткой скрывается серьезная мысль. А именно — очень просто создать безопасную систему, если вы пойдете на компромисс с функциональностью. Машина, которая ничего не делает, очень безопасна по своей природе. Проблема, стоящая перед разработчиками программного обеспечения заключается в том, как сбалансировать удобство и безопасность.
Сказка о Двух Моделях Безопасности
Многие люди утверждают, что UNIX является более безопасной, чем Windows. Однако когда требуют доказательств, они находят, что очень трудно указать на уязвимости в ядре NT. Действительно, на бумаге модель безопасности Windows явно превосходна — каждый объект имеет связанный список контроля доступа, и этот список проверяется ядром при каждой попытке доступа.
Модель UNIX, напротив, гораздо более примитивна. Только файлы имеют какой-либо контроль доступа (хотя, по справедливости говоря, большинство вещей в системе UNIX являются, как правило, файлами), который просто имеет разрешения для пользователя, группы, и всех.
Есть только два уровня безопасности:
* Пользователи могут делать все, что им позволил делать root
* Root может делать все.
Опыт подсказывает, что более простая модель обеспечивает большую безопасность, но это не всегда так. Например, VMS имеет одновременно подробную модель безопасности и превосходную репутацию по безопасности. Разница между VMS и Windows заключается в том, что VMS машины, как правило, запускаются людьми с большим опытом настройки и конфигурирования VMS. Если большая часть вашей работы — это понимание деталей модели безопасности, то вы, вероятно, придете к хорошему обеспечению безопасности этой системы. В отличие от этого, большое количество машин с Windows — это домашние машины, запускаемые людьми с маленькими познаниями в компьютерах или же вообще без знаний, или в небольших компаниях, не имеющих IT-персонала. Если пользователи VMS настраивают свою политику безопасности осторожно, то пользователи Windows попросту отключают меры безопасности, поскольку они слишком сложны для корректной настройки.
Возможно, ту же самую критику можно перенести и на UNIX. Чтобы сравнение было справедливым, давайте взглянем на Mac OS X. Построенная на ядре UNIX (хотя и не особенно традиционном во многих отношениях), OS X наследует модель безопасности UNIX. В OS X, система не препятствует пользователю в 90% случаев из того, что ему может потребоваться в повседневной деятельности. Для других видов деятельности, таких как установка обновлений, пользователю предлагается ввести пароль. Другими словами, система обеспечения безопасности держится в стороне от пути пользователя большую часть времени.
Построение хорошей системы безопасности
Представьте, что Вы хотите построить совершенную систему обеспечения безопасности.
Первая вещь, которую Вы могли бы сделать — категорирование всех вещей, которые программа может сделать безопасно.
Этот список может включать запись частного файла, созданного программой.
Вы разрешили бы программе выполнять такие действия прозрачно, в то время как другие задачи потребуют некоторой формы пользовательского подтверждения.
Как только Вы встроили систему, Вы пытаетесь выполнить приложение. Тут же пользователь получает сотни диалоговых окон с сообщениями типа:
*Эта программа только что попыталась подключиться к Интернету…
*Эта программа только что попыталась обратиться к этому файлу…
*Эти программы только что попробовали…
Пользователь нажимает OK для всех этих сообщений, и программа радостно выполняется. Однако, немного позже, выскакивает другое диалоговое окно с другим типом сообщения: «Эта программа только что попыталась изменить векторы системных вызовов ядра....»
Что делает пользователь? Он научен всеми другими диалоговыми окнами, что нажимание OK делает программу рабочей, таким образом, он нажимает OK. Ох, дорогуша, теперь rootkit установлен.
Конкретный пример подобной системы безопасности — Microsoft ActiveX. Компоненты ActiveX являются простейшими элементами управления COM — динамическими библиотеками, поддерживающими четкий интерфейс. Очевидно, Вы не хотите выполнять произвольный код на Вашей машине, поэтому Microsoft удостоверяется, что элементы управления ActiveX будут загружены, только если пользователь их хотел. Каждый раз Вы посещаете вебсайт, который содержит элемент управления ActiveX, выскакивает диалоговое окно с информацией об элементе управления, и спрашивает Вас, хотите ли Вы выполнить его. Результат? Пользователи привыкли к нажиманию OK всякий раз, когда хотел стартовать ActiveX, и существенное количество malware распространяется через этот механизм.
К сожалению, кажется, что Microsoft извлекла уроков из этой ошибки. Windows Vista показывает даже больше выскакивающих диалоговых окон, и поощряющих пользователя нажимать OK по любому связанному с безопасностью вопросу.
SELinux и Systrace
Одна разработка, которая вызвала большое количество нареканий — это SELinux, которая добавляет контроль доступа ролевого типа в Linux.
С тех пор, как впервые SELinux начала поставляться с Fedora Core, я наблюдал множество обращений в поддержку, которые проходили примерно так:
Пользователь: «Что-то не работает на моем компьютере с Fedora !»
Поддержка: «Попробуйте выключить SELinux»
Пользователь: «О! Теперь все работает, спасибо!»
В данной ситуации верным шагом для пользователя будет разбирательство, почему определенное приложение не работает с включенной SELinux, модификация соответствующей применяемой политики (или исправление кода), и затем опять включение SELinux. Однако этот шаг обычно игнорируется.
Механизм Systrace, имеющийся в OpenBSD и NetBSD, работает в противоположном направлении. В отличие от SELinux, Systrace должен выполнятся на основе процессов. Преимущество такого устройства состоит в том, что, если кое-что не работает с Systrace, пользователь должен отключить только это для конкретного приложения, а не всей системы. Несмотря на это преимущество, я подозреваю, что, как SELinux, Systrace редко используется в случаях, где политика не поставляется совместно с приложением.
Systrace, наряду с остальной частью философии OpenBSD, когда дело доходит до безопасности, говорит нам одну вещь: Люди будут работать в безопасных системах, если их будет легко обезопасить. По умолчанию, OpenBSD выполняет программы с наиболее возможными низкими привилегиями, и даже выполняет некоторые программы в окружении chroot. В общем и целом, эти службы остаются безопасными, потому что пользователю не требуется что-нибудь делать для подтверждения своих действий.
Каков же ответ?
В настоящее время цель большинства исследований безопасности в проектировании систем, которые трудно взломать с технической точки зрения, полностью игнорируя тот факт, что в большинстве систем пользователь является самым слабым звеном.
В настоящее время, многие системы «достаточно безопасны» с технической точки зрения, но большинство этих систем имеет пользовательские интерфейсы поверх них, что серьезно препятствуют их безопасности. Я хотел бы видеть систему, которая представляет новый подход к пользовательскому интерфейсу для безопасности,
но все кажутся сосредоточенными на соревновании, чтобы видеть, кто может предоставить конечному пользователю самые запутывающие варианты выбора, и наибольшее количество причин отключить сами системы, обозначаемые как «необходимые».
