Как файлы с защитой от ненадежного приложения защищены в Linux

Я запускаю машину Ubuntu Linux. Когда я запускаю приложения, написанные разными поставщиками, такими как Chrome и Firefox, я замечаю, что все они работают с моим uid. Но если это так, любой файл, который они создают в файловой системе, также будет с тем же uid. Тогда как в linux два взаимно ненадежных приложения сохраняют свои файлы друг от друга?

  • использование политики ACL в приложении A может все же позволить приложению B читать файлы A – через пользовательскую часть (пользователя, группу, другую)
  • приложениям необходимо использовать шифрование для защиты своих данных друг от друга?

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

Типичные настольные операционные системы, такие как Unix и Windows, и типичные мобильные операционные системы, такие как Android и iOS, имеют разные модели безопасности. Unix – это многопользовательская операционная система с взаимно недоверенными пользователями. Приложения считаются доверенными: все приложения пользователя запускаются в одном контексте безопасности. С другой стороны, услуги несколько менее надежны: они обычно выполняются под специальной учетной записью, чтобы уменьшить влияние в случае уязвимости безопасности.

Существуют две основные причины, по которым модель безопасности Unix работает следующим образом:

  • Отрицательная причина – история: когда Unix был разработан, приложения поступали от небольшого набора программистов и были подкреплены репутацией поставщика или предоставлены в качестве исходного кода или обоих. Бэкводы редко боялись в приложениях. Кроме того, несколько приложений были переданы по сети, поэтому было довольно мало возможностей для запуска и использования уязвимостей. Поэтому не было сильного стимула изолировать заявки друг от друга.
  • Положительная причина – это функциональность: изоляция приложений делает невозможным много вещей. Если каждое приложение имеет свою собственную область данных, что затрудняет обмен данными между приложениями. В типичной системе Unix очень часто используются одни и те же данные для нескольких приложений. Это особенно верно, поскольку Unix не имеет четкого разделения между «приложениями» и «операционной системой». Веб-браузер – это приложение. Невозможно загрузить файл в каталог по вашему выбору, потому что браузер ограничен его собственным каталогом, раздражает. Программа, которая отображает меню и значки при входе в систему, также является приложением на той же основе. Так же есть файловые менеджеры, которым по определению нужен доступ ко всем вашим файлам. Так же и оболочки и другие интерпретаторы, выполняющие скрипты повсюду. Когда вы печатаете документ из текстового процессора, это может включать приложение для преобразования документа в печатный формат и другое приложение для отправки данных на принтер.

Хотя сейчас гораздо больше авторов приложений, чем 40 лет назад, приложения по-прежнему обычно распространяются через доверенные каналы, которые имеют показатель репутации. (Это явно более верно для Linux, чем для Windows, что является частью причины, по которой вирусы чаще встречаются в Windows). В приложении обнаружено, что бэкдор будет быстро извлечен из репозиториев программного обеспечения Linux.

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

Изоляция приложений начинает поступать на настольные системы Unix. Некоторые дистрибутивы запускают определенные программы в рамках безопасности, такие как AppArmor или SELinux, которые ограничивают возможности приложения. Стоимость этих ограничений безопасности заключается в том, что они иногда делают желательным использование невозможным, например, предотвращение открытия ограниченным приложением файлов в определенных каталогах.

Шифрование было бы совершенно бесполезным. Шифрование только защищает данные в пути (по сети) или в состоянии покоя (хранится на диске), оно не защищает данные в живой системе – если подсистема A расшифровывает свои данные, то это зависит от ОС, чтобы предотвратить подсистему B, чтобы предотвратить доступ к дешифрованным данным, и, следовательно, не имеет значения, были ли данные дешифрованы A или сохранены в незашифрованном виде. Операционная система может шифровать данные, но только для защиты, если украден носитель данных.

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

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

Мне нравится ответ Гилла, но есть еще один аспект:

Принцип unix заключается в том, что каждая программа должна «хорошо делать одно».

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

В крайнем примере принципа: один из старых почтовых программ unix, которые почти никто не использует больше, elm , просит вашего одобрения, прежде чем создавать каталоги, которые он будет использовать для хранения своего файла конфигурации ( ~/.elm/ ) и почтовых папок ( ~/Mail/ ). Если вы скажете «нет», он отвечает

 Very well, but you may run into difficulties later. 

Противоположная крайность была продемонстрирована некоторыми программами, которые я пытался запустить в последнее время (извините, я забыл, какой), которые отказались начать, и не дал никаких указаний о том, что было не так. strace показал, что он хотел создать каталог с именем ~/.config/ и не мог, потому что у меня был обычный файл с таким именем. (Я когда-то делал cp .config ~ из дерева исходных кодов ядра, поэтому у меня была бы резервная копия.) По-видимому, сейчас считается разумным топать по очень родовому имени в домашнем каталоге пользователя без уведомления (гораздо меньше одобрения) или даже минимальная проверка ошибок.

Прогресс.