В большинстве случаев при установке программы из исходного кода рекомендуется создать нового пользователя и новую группу и предоставить /usr/local/<myapp>недавно созданным пользователям и группам право собственности.
Почему такая практика считается хорошей практикой?
Что это улучшает?
Пример: mysql user / mysql group для сервера базы данных MySQL.
Ответы:
Практика заключается не в создании одного пользователя и группы для приложения, а для каждой службы. То есть программы, которые выполняются локальным пользователем, не нужно устанавливать как пользователь, отличный от пользователя root. Это демоны , программы, работающие в фоновом режиме и выполняющие запросы, поступающие через сеть или другие средства связи, которые должны запускаться как выделенный пользователь.
Демон запускается как выделенный пользователь, поэтому, если он плохо себя ведет (из-за ошибки, возможно, вызванной злоумышленником), ущерб, который он может нанести, ограничен: затрагиваются только файлы данных демона (если злоумышленнику не удалось найти локальную корневую дыру) , что может случиться). Например, демон базы данных mysqldработает как выделенный пользователь и группа, mysql:mysqlи файлы данных базы данных ( /var/lib/mysql/*) принадлежат mysql:mysql.
Обратите внимание, что исполняемый файл демона и другие статические данные и файлы конфигурации, которые используются, но не должны изменяться демоном, не должны принадлежать выделенному пользователю; они должны принадлежать root:root, как и большинство программных и конфигурационных файлов. mysqldПроцесс не имеет никакого бизнеса , перезаписи /usr/sbin/mysqldили /etc/mysql/my.cnf, так что эти файлы не должны принадлежать к mysqlпользователю или быть доступны для mysqlпользователя или mysqlгруппы. Если некоторые файлы должны быть доступны для чтения только демону и администратору, они должны принадлежать пользователю root и выделенной группе и иметь режим 0640 ( rw-r-----).
Особой категорией исполняемых файлов, которые не могут принадлежать владельцам, root:rootявляются программы, которые вызываются пользователем, но должны запускаться с дополнительными привилегиями. Эти исполняемые файлы должны быть setuid root, если они должны запускаться (хотя бы частично) как root; тогда исполняемый файл должен иметь режим 4755 ( rwsr-xr-x). Если программе нужны дополнительные привилегии, но не root, то для программы нужно установить setgid, чтобы дополнительные привилегии приходили через группу, а не через пользователя. Исполняемый файл имеет режим 2755 ( rwxr-sr-x). Причины двоякие:
В общем, это не приложения, а демоны. Причина в том, что демон может работать как непривилегированный пользователь вместо root, так что, если он имеет уязвимость безопасности и скомпрометирован, ущерб, который может быть нанесен, будет распространяться только на те области, к которым у пользователя есть доступ.
Причина, по которой это считается хорошей практикой, состоит в том, чтобы предотвратить переопределение другими пользователями системы данных и файлов конфигурации для конкретного приложения.
В качестве примера mysql/ mysqlявляясь владельцем хранилища для файлов базы данных mysql, никто не использует API приложения от повреждения баз данных. Кроме того, у пользователя mysqlобычно нет настоящей оболочки, поэтому никто не может войти в систему под этим пользователем.
/usr/bin/atпринадлежит daemon/daemonUbuntu
atне демон Он настроен daemonтак, что может общаться с atdдемоном через личные файлы.
Создание новой группы / пользователя для нового установленного демона повышает безопасность. Когда серверный процесс запускается от имени такого пользователя, он ограничивается правами доступа этого пользователя. Для сравнения: когда он запускается как root, он может делать все.
Это различие важно в случае, если ваш демон неправильно настроен и / или содержит ошибку, связанную с безопасностью.
Я не уверен, что вы имеете в виду под второй частью вашего вопроса, то есть частью о /usr/localсобственности. В общем случае не имеет смысла, что тот же пользователь, Xпод которым запускается демон из соображений безопасности, также владеет каталогом с двоичными файлами (поскольку в этом случае он может изменить их в случае эксплойта). Но каталог с файлами данных, с которыми работает демон, должен быть доступен X- самый простой способ настроить это - создать Xвладельца каталогов / файлов данных.
Запуск демона под своим собственным специальным пользователем - это всего лишь одна техника безопасности, другие включают в себя своего рода «хроматирование» или использование системы обязательного контроля доступа (MAC) (например, SELinux).
Это соображение безопасности. Это ограничивает ущерб, который может нанести кто-нибудь, взломавший приложение демона. Пользовательские приложения обычно принадлежат стандартному идентификатору пользователя, например root.
Если ваш веб-сервер, почтовый сервер и база данных работают под одним и тем же пользователем, это облегчает их компрометацию. Если какой-либо из них имеет ошибку или неправильную конфигурацию, которые позволяют доступ к системе, этот доступ может быть использован для доступа ко всем трем приложениям.
Если все они имеют отдельные учетные записи, как рекомендуется, вероятно, будет доступно только скомпрометированное приложение. Хотя общедоступные подробности конфигурации других могут быть прочитаны, маловероятно, что изменения могут быть сделаны.
Многие демоны позволяют пользователям загружать и скачивать файлы и в противном случае делать то, что вы не хотели бы, чтобы они могли делать с конфигурациями других демонов. Если у каждого приложения есть свой идентификатор пользователя и группа, проще защитить демоны.
Наличие определенной группы демона упрощает безопасное предоставление демону безопасного доступа только для чтения к файлам и каталогам. Если файл или каталог принадлежит другому пользователю, но принадлежит группе демонов, он обычно будет доступен только для чтения. Права доступа можно легко проверить и исправить с помощью таких инструментов, как find.