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

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

 

Данный пост является критикой существующего подхода к обеспечению безопасности в современных операционных системах. Помимо критики будут предложены пути решения данных вопросов. Рассмотрен будет 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 запущенных с привелегиями рута разрешаем пользователю писать в этот файл, затем пользовательскими средствами пишем и потом опять закрываем, чтоб другим неповадно было.

Выводы:

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

Пример 2

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

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

 

Акт первый

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

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

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

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

 

Акт первый

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

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

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

Теперь о том, зачем я это написал

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

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

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

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

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

Заключение

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

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

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

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

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

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

 

 

Добавить комментарий

Войти с помощью: