Почему рекомендуется создать группу и пользователя для некоторых приложений?

Практика не должна создавать одного пользователя и группу на приложение, но на сервис. Таким образом, программы, которые выполнены локальным пользователем, не должны быть установлены как пользователь кроме корня. Это - демоны, программы, работающие в фоновом режиме и которые выполняют запросы, проникающие через сеть или другие коммуникационные средства, которые должны работать как преданный пользователь.

Демон работает как преданный пользователь так, чтобы, если это неправильно себя ведет (из-за ошибки, вероятно, инициированной взломщиком) повреждение, это могло сделать, ограничен: только файлы данных демона затронуты (если взломщику не удалось найти локальную корневую дыру, которая может произойти). Например, демон базы данных mysqld выполнения как преданный пользователь и группа mysql:mysql и файлы данных базы данных (/var/lib/mysql/*) принадлежите mysql:mysql.

Обратите внимание, что исполняемый файл демона и другие статические данные и конфигурационные файлы, которые используются, но не должны быть изменены демоном, не должны принадлежать преданному пользователю; они должны принадлежать root:root, как большая часть программы и конфигурационных файлов. mysqld процесс не имеет никакой бизнес-перезаписи /usr/sbin/mysqld или /etc/mysql/my.cnf, таким образом, эти файлы не должны принадлежать mysql пользователь или быть перезаписываемым mysql пользователь или mysql группа. Если некоторые файлы должны быть читаемыми только демоном и администратором, они должны принадлежать пользовательскому корню и специализированной группе и иметь режим 0640 (rw-r-----).

Специальная категория исполняемых файлов, которые не могут находящимся в собственности root:root программы, которые вызываются пользователем, но должны работать с дополнительными полномочиями. Эти исполняемые файлы должны быть корнем setuid, если они должны работать (по крайней мере частично) как корень; затем исполняемый файл должен иметь режим 4755 (rwsr-xr-x). Если потребности программы с дополнительными полномочиями, но не как корень, то программа должна быть сделана setgid, так, чтобы дополнительные полномочия проникли через группу а не через пользователя. Исполняемый файл затем имеет режим 2755 (rwxr-sr-x). Причины являются двукратными:

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

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

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

Как пример mysql/mysql быть владельцем устройства хранения данных для mysql файлов базы данных предотвращает любого не использование приложения API от повреждения баз данных. Плюс пользователь mysql обычно не имеет реальной оболочки, таким образом, никто не может войти в систему как тот пользователь также.

Создание новой группы/пользователя для нового установленного демона улучшает безопасность. Когда серверный процесс выполняется при таком пользователе, он ограничивается правами доступа того пользователя. В сравнении: когда это выполняется как корень, это может сделать все.

Это различие важно в случае, если Ваш демон неправильно конфигурируется и/или содержит связанную с безопасностью ошибку.

Я не уверен, о чем Вы имеете в виду со второй частью Вашего вопроса, т.е. частью /usr/local владение. В целом это не имеет смысла что тот же пользователь X под которым демон работает за соображениями безопасности, также владеет каталогом с двоичными файлами (потому что в этом случае он мог изменить их в случае использования). Но каталог с файлами данных, демон продолжает работать, должен быть доступным X - самый легкий способ настроить это состоит в том, чтобы сделать X владелец каталогов/файлов данных.

Выполнение демона при его собственном специальном пользователе является всего одним методом безопасности, другие включают своего рода 'chrooting' или использующий систему мандатного управления доступом (MAC) (например, SELinux).

Это - соображение безопасности. Это ограничивает ущерб, который может быть нанесен кем-то, кто врывается в приложение демона. Пользовательское приложение обычно принадлежит стандартному идентификатору пользователя такой как root.

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

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

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

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