Linux Least Privilege: Root, sudo & Privilege Paths

Root, sudo và Least Privilege trên Linux Server là bài toán về privilege paths: identity nào có thể trở thành root, chạy command với quyền cao hơn hoặc tác động gián tiếp tới tài nguyên đặc quyền. Bài này không sở hữu SSH authentication hay chmod/chown chi tiết; SSH remote access thuộc SSH Hardening, còn filesystem permission thuộc File Permission & Ownership.

Mục tiêu là giảm số đường dẫn tới full privilege nhưng vẫn giữ được vận hành và recovery. Một user không có UID 0 vẫn có thể đạt quyền tương đương root qua sudo rule quá rộng, writable root-executed script, service control hoặc automation credential. Vì vậy owner task ở đây là identity → required task → privilege path → scope → validation → final state.

Identity và direct sudo controls

UID 0 có quyền rất rộng trên Linux: process, network, service, file và account đều có thể bị thay đổi. Vì vậy audit không chỉ hỏi “root password có bị khóa không?”, mà hỏi những identity nào có thể đạt UID 0 hoặc tác động tương đương.

Ubuntu thường dùng named user + sudo thay cho shared root password. Điều này giúp attribution tốt hơn, nhưng chỉ an toàn nếu sudo policy thực sự được scope và log.

2. Inventory privileged identities

getent passwd
getent group sudo
getent group wheel

Phân loại:

Human admin: người vận hành thực tế.
Service account: daemon/application identity.
Automation account: deploy, backup, orchestration.
Break-glass: recovery path đặc biệt.
Legacy/unknown: chưa rõ owner hoặc purpose.

Unknown identity không nên bị xóa ngay trên production; trước tiên cần map process, job, ownership và integration dependency.

3. Review sudo theo effective privilege

sudo -l
sudo -l -U username

Đọc cả target user, allowed command và argument scope. Một rule có vẻ hẹp nhưng command hỗ trợ shell escape, editor, plugin hoặc arbitrary file write vẫn có thể trở thành privilege escalation path.

Đừng đánh giá sudo chỉ bằng group membership. User ngoài group sudo/wheel vẫn có thể có rule riêng trong /etc/sudoers.d/.

4. Sửa sudoers bằng công cụ có validation

Tránh sửa trực tiếp bằng editor không kiểm syntax. Dùng:

sudo visudo
sudo visudo -f /etc/sudoers.d/role-name

Tooling cụ thể có thể khác theo distro/version, nhưng nguyên tắc là policy phải được parse/validate trước khi phụ thuộc vào nó cho production access.

5. Full sudo chỉ dành cho vai trò thật sự cần

Rule như:

%admins ALL=(ALL:ALL) ALL

có thể phù hợp với system administrators, nhưng không phải default cho developer/vendor/operator. Nếu role chỉ cần restart một service hoặc đọc log, hãy thiết kế privilege gần với task thực tế hơn.

Least privilege không có nghĩa sudoers phải cực kỳ phức tạp. Policy quá chi tiết nhưng không maintain được cũng tạo risk. Scope phải vừa đủ, dễ review và có owner.

6. NOPASSWD cần justification riêng

NOPASSWD có use case hợp lệ cho automation hoặc runbook cụ thể, nhưng nó làm giảm friction khi credential/session đã bị compromise. Khi dùng:

Scope identity rõ.
Scope command/argument rõ.
Credential của caller được bảo vệ.
Action được log.
Review lại khi automation thay đổi.

7. Tránh root shell như chế độ làm việc mặc định

sudo -i và root shell kéo dài làm giảm khả năng nhìn từng privileged action. Với task thường ngày, ưu tiên nâng quyền sát command cần thiết. Root shell vẫn có thể cần trong recovery hoặc incident phức tạp, nhưng phải là ngoại lệ có owner.

Service, automation và indirect privilege paths

8. Service account và automation account cần privilege riêng

Web runtime, database, backup, monitoring và deploy không nên dùng chung một privileged identity. Mỗi workload cần account riêng theo purpose; interactive shell và sudo chỉ tồn tại khi workload thật sự cần.

Với service account, câu hỏi chính ở bài này là nó có thể làm gì với privilege?. Câu hỏi file/path cụ thể đọc-ghi-execute thế nào thuộc File Permission & Ownership.

9. Deploy identity và runtime identity

Deploy process có thể cần quyền thay release hoặc reload service; web runtime thường chỉ cần chạy application. Hai identity này nên được tách khi architecture cho phép để application compromise không tự động có deploy privilege.

Chi tiết owner/group/mode của source tree và writable runtime paths thuộc filesystem owner page, không lặp lại trong bài này.

10. Indirect privilege path

Privilege escalation không chỉ đến từ sudo. Một user có thể có đường gián tiếp nếu:

Có quyền sửa script/unit/config mà root sẽ execute.
Có quyền control một privileged service.
Có credential của automation có full privilege.
Có capability/setuid path nguy hiểm.

Bài này chỉ xác định privilege relationship; cách kiểm owner/mode/ACL của file thuộc 335.

11. SSH key lifecycle không phải owner chính của bài này

SSH key chỉ liên quan ở đây khi key đó cấp access cho một privileged identity. Authentication method và allowed login thuộc SSH Hardening; rotation/revocation secret thuộc Server Secrets Management.

12. Logging và accountability

Sudo action nên gắn được với user gốc. Tùy distro, có thể kiểm qua journal/auth log:

journalctl _COMM=sudo --since '24 hours ago' --no-pager

Logging không thay authorization, nhưng giúp biết ai dùng privilege, khi nào và kết quả ra sao.

13. Break-glass access

Server critical cần recovery path khi access bình thường hỏng. Break-glass có thể là console/account riêng, credential được bảo vệ, có alert và review sau sử dụng.

Break-glass không phải shared root account dùng hằng ngày. Nếu nó được dùng thường xuyên, nó không còn là recovery control.

14. Safe privilege reduction workflow

Inventory identity + owner.
Map required task.
Read current sudo/group/service privilege.
Xác định direct và indirect privilege paths.
Thiết kế expected scope.
Giữ recovery path.
Thay một role/rule mỗi lần.
Validate sudoers.
Test task hợp lệ vẫn chạy.
Test task ngoài scope bị từ chối khi phù hợp.
Review log và dependency.
Ghi final state + rollback.

Privilege Path Register

Artifact này ghi đường privilege, không ghi chi tiết chmod/ACL.

Identity	Required task	Current path	Target privilege	Evidence	Decision
Human admin	System admin	sudo/full sudo	Role-appropriate	`sudo -l`	KEEP/REDUCE
Deploy	Deploy/reload	Automation + sudo	Task-scoped	Pipeline + sudoers	KEEP/REDUCE
Service	Run application	Service identity	No interactive privilege	Unit/process config	KEEP/FIX
Break-glass	Recovery	Privileged	Controlled emergency only	Vault/alert/test record	KEEP

Checklist Least Privilege

Named human admins.
Review sudo/wheel và sudoers.d.
Full sudo chỉ cho role cần thiết.
NOPASSWD có justification.
Service/automation identity tách theo workload.
Interactive shell không cấp ngoài nhu cầu.
Root shell không là default workflow.
Indirect privilege paths được review.
Break-glass có owner và test.
Privileged actions có log.
Privilege reduction có rollback và functional test.
Review sau offboarding/deploy architecture change.

Nguồn kỹ thuật tham khảo

Kết luận

Owner của Least Privilege là privilege path: ai có thể trở thành root hoặc thực hiện hành động đặc quyền, qua sudo/service/automation/indirect path nào và scope đó có thực sự cần thiết không.

SSH authentication thuộc 331; chmod/chown/ACL thuộc 335. Tách các owner này giúp bài 332 tập trung vào câu hỏi quan trọng nhất: WHO can do WHAT with elevated privilege?