必须为服务创建独立用户和组，以实现进程隔离、资源限制与审计溯源，防止提权后横向渗透。需用useradd -r -s /sbin/nologin -M -U创建系统用户，配合文件权限、Capability精简、SELinux/AppArmor及systemd安全选项实施最小权限。
Linux系统中，为服务分配独立的用户和组，并遵循最小权限原则，是提升安全性的基础措施。核心思路是：每个服务运行在专属低权限账户下，不复用root或通用系统账户，且该账户仅拥有完成自身功能所必需的文件、目录、端口和系统能力。
为什么必须为服务创建独立用户和组
默认情况下，许多服务（如Nginx、Redis、PostgreSQL）安装后会自动创建专用系统用户（如www-data、redis、postgres），这并非巧合。若服务以root身份运行，一旦被利用，攻击者将直接获得最高权限；若多个服务共用同一普通用户（如daemon），一处漏洞可能横向影响其他服务。独立账户能实现进程隔离、资源限制与审计溯源。
创建服务专用用户和组的操作要点
使用useradd命令创建无登录能力、无家目录、无shell的系统用户：
- useradd -r -s /sbin/nologin -M -U myapp：-r表示系统用户，-s /sbin/nologin禁止交互登录，-M跳过家目录创建，-U自动创建同名主组
- 避免使用-u硬编码UID，让系统自动分配，防止冲突；如需固定UID（如集群环境），应先检查/etc/passwd及系统保留范围（通常1–999）
- 确认用户属于正确组，必要时用usermod -aG neededgroup myapp追加附加组（如disk仅当需访问特定块设备时才添加）
权限最小化落地的关键环节
创建用户只是起点，还需同步约束其可访问的资源：
- 文件与目录权限：服务配置文件、数据目录、日志路径均应归属服务用户，权限设为750（目录）或640（文件），禁止world可读写
- Capability精简：通过systemd服务单元文件限制Linux capabilities，例如CapabilityBoundingSet=CAP_NET_BIND_SERVICE仅允许绑定低端口，禁用CAP_SYS_ADMIN等高危能力
- SELinux/AppArmor策略：启用强制访问控制，定义服务仅能读取自身配置、写入指定日志路径、监听特定端口，即使用户被提权也无法越界操作
- 禁用不必要的shell和认证方式：确保/etc/passwd中该用户shell为/sbin/nologin或/usr/sbin/nologin，且不在/etc/shadow中设置有效密码（或设为*）
常见服务配置示例（systemd）
以自定义Web服务myapp为例，在/etc/systemd/system/myapp.service中明确指定运行身份与权限边界：
[Service] User=myapp Group=myapp NoNewPrivileges=true RestrictRealtime=true ProtectSystem=strict ProtectHome=true PrivateTmp=true CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID
启用后执行systemctl daemon-reload && systemctl restart myapp，再用ps aux | grep myapp验证进程确由myapp用户启动。
