Вопросы безопасности операционных систем

Данный пост является критикой существующего подхода к обеспечению безопасности в современных операционных системах.

🕛 26.04.2010, 23:50

Кроме критики будут предложены способы разрешения данных вопросов. Рассмотрен будет Linux, однако думаю что ситуация так же плачевна в BSD и остальных Unix, включая MACOS, на Windows это также распространяется. Этот пост является выражением личного мнения, формировавшегося последние несколько лет пользования разными дистрибутивами Linux и Windows, Mac OS X.

Что мне собственно не нравится? А не нравится мне система пользователей. Она, естественно, лучше чем ничего, однако весьма слаба. Все ограничения, права и прочие штуки по безопасности происходят от того что мы не доверяем программному обеспечению: мы не доверяем браузерам, для которых есть эксплоиты, PDF вьюверам, не говоря уже о новом программном обеспечении полученном из недостоверного источника. Получено оно в бинарном виде или в исходниках не особенно оказывает влияние на ситуацию. Скомпрометированная версия исходников программы также опасна.

Итак пример

В качестве примера возьмём настройку монитора. Для этого нужно соответствующим образом описать желаемое в /etc/X11/xorg.conf. Сделать это возможно путём запуска утилиты xorgconfig или редактированием xorg.conf именно в текстовом редакторе. Однако здесь есть оно однако: права на запись данного файла принадлежат суперпользователю.

Способы разрешения:

1. Запускаем xorgconfig от рута, конфигурируем, пишем.
2. Запускаем xorgconfig от себя, создаём конфигурационный файл, сохраняем собственной папке и позже от рута с помощью cat или cp переписываем xorg.conf.
3. Запускаем от рута текстовый редактор и идём редактируем.
4. С помощью утилит chown или chmod запущенных с привелегиями рута разрешаем пользователю писать в этот файл, после пользовательскими средствами пишем и позже снова закрываем, чтобы иным неповадно было.

Выводы:

Что мне не нравится: так или иначе 1 из программ получает рутовые права, все рутовые права! Я, как пользователь, желал, чтоб соответствующая программа лишь писала в xorg.conf, а она сейчас может переписать пароли и всё что захочет, сделать пользователя, добавить модуль ядра, да всё что угодно! Да я понимаю что мы доверяем программному обеспечению написанному коммьюнити, однако там где нужна безопасность доверия нет. Программы приходят по каналам связи, пишут их люди, и даже при получении хорошего дистрибутива никто не гарантирует ошибочной обработки данных, которая может привести к выполнению произвольного кода.

Пример 2

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

Нормально предприятие

Акт I

Директор токарю:"Вот чертёж, заготовки и резцы на складе, сроку 3 дня."
Токарь на складе:"Дайте мне резцы и заготовки!"
Охрана склада:"С какого это перепугу?"
Токарь:"А вот указание директора и разрешения получить на складе 5 заготовок и 3 резца."
Охрана:"Получи и распишись!"

Прошло 3 дня, токарь изготовил детали, пришло время отгрузки. Акт II-й

Водитель выезжает с территории завода с грузом, проходная.
Водитель:"Откройте ворота!"
Охрана:"Чего везёшь? Мы на то и охрана чтобы кто попало пол завода не вывез!"
Водитель:"А вот заказ, накладная, описание груза и его число, дата вывоза и пункт назначения, вот разрешение на вывоз с территории завода!"
Охрана проверяет бумаги, проверяет груз и отпускает водителя.

Предприятие с безопасностью в стиле Unix

Акт I

Директор токарю:"Вот чертёж, заготовки и резцы на складе, сроку 3 дня."
Токарь на складе:"Дайте мне резцы и заготовки!"
Охрана склада:"С какого это перепугу?"
Токарь директору:"Не дают на складе ничего, прав нету."
Директор токарю:"Вот тебе доверенность на полное управление заводом от имени директора!"
Токарь:"Спасибо!"

Прошло 3 дня, токарь изготовил детали, пришло время отгрузки. Акт II-й

Водитель выезжает с территории завода с грузом, проходная.
Водитель:"Откройте ворота!"
Охрана:"Чего везёшь? Мы на то и охрана чтобы кто попало пол завода не вывез!"
Водитель директору:"Охрана ворота не открывает, как же я отвезу заказ то?"
Директор водителю:"Вот тебе доверенность на полное управление заводом от имени директора!"
Водитель:"Спасибо!"

Сейчас о том, для чего я это написал

По-моему пользователи в системе обязаны соответствовать лишь людям, никакого супер пользователя быть не должно. Программа которая обязана переписать системный конфигурационный файл обязана получить права лишь на запись этого файла и ничего более. Это должно естественным путём продолжить Unix way:"1 задача - 1 программа" и позволять программам делать лишь то что они обязаны.
Кто это должен контролировать? Ос. По определению, ос это набор программного обеспечения для предоставления клиентским программам доступа к оборудованию. Так вот она и обязана это контролировать. Программа использует системные функции для работы с файлами и устройствами, так вот эти функции и обязаны проверять, есть ли соответствующий допуск. Не так, как это сделано теперь, когда просто проверяется соответствующий пользователь, и что он может. Даже простой текстовый редактор, который пользователь запускает для редактирования файла должен получить права лишь на этот файл и никаких иных! Спасибо, что читаете настолько немало букв. В данный миг когда пользователь запускает vim с именем файла в качестве параметра консольный интерпретатор только парсит строку, вызывает vim и кормит ему характеристики, в принципе vim может спокойно проигнорировать указанный параметр и делать всё что захочет со всеми файлами пользователя. 1 из способов решения заключается в том, чтоб OS контролировала, что пользователь желает. Характеристики командной строки и системные диалоги выбора файла обязаны обрабатываться OS и лишь к этим файлам программа обязана получить доступ. Точно также случается при инсталляции программ и пакетов. Программа удаляется сама (имеет скрипт удаления), однако это же ужасно! Разве не ОС выдала диск программе под конкретные файлы, разве не задачей ОС является управление и выдача систем программам? Если в ресторане не будет уборщиков, то даже при аккуратных посетителях он превратится в помойку. Это прямая функция ОС, забрать у программы то, что её когда-то выдали, а не вежливо попросить её самоудалиться и позже даже не контролировать что осталось. ОС при установке обязана логировать что куда установилось, что поправилось и при удалении возвращать всё на место.

Способы решения в существующих Unix

Частичный костыль для решения таких проблем это создание кучи пользователей для различных действий, к примеру пользователя который может лишь править xorg.conf и тому таких, однако это большое число пользователей и просто невозможность трудиться на таком компьютере, будет нужно помнить какому пользователю что позволено и всё запускать от таких пользователей, а чуть необычное воздействие, и снова брать рута и создавать соответствующего пользователя на конкретное воздействие.

Способы решения в новых OS

Я предлагаю сделать что-то вроде доверенностей, которые выдаёт пользователь, т.е. передачи части прав пользователя программе, а не всех. Т.е. к примеру браузер должен иметь возможность лишь запрашивать из сети информацию, отправлять информацию, писать свои кеши в определённое место на диске и сохранять бумаги в отведённое пользователем место на диске, он не должен иметь права на чтение всех юзерских документов. А то обновился браузер не по https, пользователь его запустил и все бумаги пользователя ушли хакеру Пете, и никто не заметил. Я предлагаю что-то вроде фаерволла не только лишь для сети но еще и для диска и прочего оснащения. И самое основное это не обязана быть песочница, виртуализация, IL машина или прочие интерпретируемые технологии, весьма возможно реализовать это в нативном коде, просто функции операционной системы обязаны проверять что просил пользователь и что делает программа. Запуск программ для обработки данных обязана совершать ос, и она обязана знать какие данные желает обработать пользователь, и дать программе возможность обработать лишь их.

Заключение

Давать программам немало прав - плохо, требуется целиком переделывать систему безопасности современных ОС.
Нерешёных вопросов ещё немало, неграмотных пользователей ещё более, однако, думаю, исправлять существующее положение требуется. UAC от Microsoft движется в этом направлении, однако как-то кривовато.

PS: По вопросам опечатак и неточностей прошу обращаться в хабрапочту.

Дополнительный пример

Как вы как правило (из шелла) запускаете фильм: mplayer filename.avi

В этом случае запускается программа mplayer, и она может делать все, что может делать юзер, однако она не стирает все юзерские файлы (впрочем могла б - спасибо ей), а лишь только читает указанный filename.avi. Это если программа "добрая", на что мы рассчитывать не можем.

Я предлагаю, чтоб при выполнении mplayer filename.avi
ОС запретила mplayer'у все-все-все, однако дала доступ к filename.avi. Результат таков что пользователь не вылез за свои права и программа заполучила нужные права, и не может похитить ваши бумаги. Никаких дополнительных телодвижений с позиции юзера нет. Юзеру не мешает, что он явно написал, то система разрешает, не ограничивает его.