Linux默认为新用户创建同名私有组以增强隔离性，加固需确保USERGROUPS_ENAB=yes或ADD_GROUP=yes，禁用ADD_EXTRA_GROUPS和pam_group.so等隐式组分配，并通过useradd -D及id命令验证配置生效。
Linux 系统默认创建用户时会自动生成同名私有组（private group），这是大多数现代发行版（如 RHEL、CentOS、Fedora、Ubuntu）的默认行为。该机制本身是安全增强设计，但若未理解其逻辑或被误配，反而可能削弱权限控制。加固关键在于明确组策略意图、避免隐式组继承、防止新用户意外获得过高组权限。
理解私有组机制与默认行为
当执行 useradd username 且未指定 -g 或 -G 时：
- 系统自动创建一个与用户名同名的组（GID 通常从 1000 起递增），并设为该用户的主组（primary group）
- 用户不会自动加入
wheel、sudo、docker等特权组，除非显式配置或模板中预设 - 该机制隔离了用户文件默认权限（如
umask 002下，同组可写；但私有组仅含本人，实际等效于仅用户可写）
修改默认用户组策略（/etc/adduser.conf 或 /etc/login.defs）
不同发行版配置文件不同，需确认实际路径：
-
Debian/Ubuntu 系统：编辑
/etc/adduser.confADD_GROUP=yes（保持启用私有组）GROUPNAME=username（确保私有组名与用户名一致，勿设为users等共享组）USERS_GID=100（慎改！此为系统组起始 GID，非用户私有组范围） -
RHEL/CentOS/Fedora 系统：编辑
/etc/login.defsCREATE_MAIL_SPOOL yes（无关组策略，但常被连带检查）GID_MIN 1000和GID_MAX 60000（限定私有组 GID 分配范围，避免与系统组冲突）USERGROUPS_ENAB yes（必须为yes才启用私有组；设为no则所有新用户主组均为users，严重削弱隔离性，不推荐）
禁用隐式组继承，收紧新用户初始权限
默认策略下，用户仍可能通过 shell 配置或 PAM 模块意外获得额外组成员身份。需主动清理：
- 检查
/etc/adduser.conf中ADD_EXTRA_GROUPS是否为no（Ubuntu 默认yes，会将用户加入dialout、cdrom等硬件组，存在物理设备提权风险） - 审查
/etc/pam.d/common-auth（Debian系）或/etc/pam.d/system-auth（RHEL系），移除类似pam_group.so的无条件组分配规则 - 禁止在
/etc/skel/中放置含newgrp、sg或groups修改的 shell 初始化脚本
审计与验证配置生效
完成修改后，务必测试并确认行为符合预期：
- 运行
useradd -D查看当前默认参数（注意GROUP字段是否为空，空值表示启用私有组） - 新建测试用户：
useradd -m testuser，然后执行：id testuser→ 确认gid=testuser(1001)且无多余groups:条目getent group testuser→ 确认组存在且仅含该用户 - 检查
/etc/group中新组 GID 是否落在GID_MIN/GID_MAX范围内，且不与已有系统组重叠
