为什么建议为某些应用程序创建组和用户？

Question

大多数情况下，从源代码安装程序时，建议创建一个新用户和一个新组，并赋予/usr/local/<myapp>最近创建的用户和组所有权。

• 为什么这种做法被认为是一种好的做法？

• 它有什么改进？

示例：MySQL 数据库服务器的 mysql 用户/mysql 组。

Answer 1

实践不是为每个应用程序创建一个用户和组，而是为每个服务创建一个用户和组。也就是说，由本地用户执行的程序不需要以 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是由用户调用但需要以额外权限运行的程序。如果这些可执行文件需要（至少部分地）以 root 身份运行，它们必须是setuid root；那么可执行文件必须具有模式 4755 ( rwsr-xr-x)。如果程序需要额外的权限而不是 root，那么应该将程序设置为 setgid，这样额外的权限来自组而不是用户。然后可执行文件具有模式 2755 ( rwxr-sr-x)。原因有二：

• 不应该允许可执行文件修改自身，以便如果用户设法利用漏洞，他们可能能够修改程序使用的数据文件，但不会在可执行文件中注入特洛伊木马以攻击运行该程序的其他用户.
• 可执行文件的数据文件属于该组。setuid 程序必须在与用户交互的真实用户（调用程序的用户）和与有效用户（程序运行的用户）交互以访问其私有数据文件（其原因）之间切换有额外的特权）。setgid 程序还可以隔离只能由组访问的每个用户的数据（例如，通过将用户拥有的文件存储在只能由 root 和程序组访问的目录中）。

Answer 2

它不是一般的应用程序，而是用于守护进程。原因是守护进程可以作为非特权用户而不是 root 运行，这样如果它有安全漏洞并受到威胁，可以造成的损害只包含在用户有权访问的区域。

Answer 3

它被认为是良好实践的原因是防止系统的其他用户覆盖特定应用程序的数据和配置文件。

例如mysql，mysql作为 mysql 数据库文件存储的所有者，可以防止任何不使用应用程序 API 的人损坏数据库。另外，用户mysql通常没有真正的 shell，因此也没有人可以以该用户身份登录。