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

 

 

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *