Sau bài này bạn làm được: đọc ls -lgetfacl để hiểu ai được đọc/ghi file; thiết kế user/service account hợp lý; viết snippet sudoers an toàn (không ALL=(ALL) NOPASSWD: ALL cho app user); giải thích cho dev vì sao container “root” khác root trên host.


Identity trên Unix: UID là sự thật, username là nhãn

Kernel và filesystem lưu số UID/GID. passwd chỉ là bảng ánh xạ UID → tên hiển thị + shell + home.

id
id nginx 2>/dev/null || id www-data 2>/dev/null
getent passwd root | cut -d: -f1,3,4,6,7

Service account thường có shell /usr/sbin/nologin hoặc /bin/falsecố ý để không đăng nhập tương tác; vẫn có thể sudo -u nginx cmd nếu policy cho phép.


passwd, group, shadow

FileAi đọc đượcNội dung nhạy cảm
/etc/passwdmọi userusername, UID, GID, home, shell
/etc/groupmọi usergroup membership
/etc/shadowrootpassword hash, aging policy

Ops: nếu bạn thấy account có password hash mạnh nhưng vẫn bị brute-force SSH — vấn đề có thể không nằm ở hash mà ở biên (password auth bật, fail2ban thiếu).


Permission bits: đọc rwx theo “chủ — nhóm — khác”

ls -l /etc/shadow
# -rw-r----- root shadow  → chỉ root và group shadow

ls -ld /var/www
# drwxr-xr-x → chủ rwx, nhóm và other chỉ r-x (thư mục: x = quyền cd)

Thư mục vs file: bit x trên thư mục là quyền đi qua (traverse), không phải “thực thi” file bên trong theo nghĩa binary.

SUID/SGID/Sticky: chmod u+s (setuid) — cực kỳ hiếm cần trên server hiện đại; sticky trên /tmp (t) là pattern chống xoá file người khác.


umask: file mới sinh ra với permission nào?

umask
# 0022 thường thấy → file 644, dir 755 sau khi mask

Ứng dụng: app tạo file log với umask quá “mở” có thể để lộ dữ liệu cho “others”. Kiểm tra umask trong unit systemd (UMask=) là một vector hardening.


ACL (Access Control List) — khi chmod g+w không đủ

# Xem ACL (cần filesystem hỗ trợ ACL, mount với acl)
getfacl /var/shared/app 2>/dev/null | head -20

ACL hữu ích khi nhiều group cần quyền khác nhau trên cùng tree — nhưng ACL cũng làm audit khó hơn. Quy tắc: nếu ACL phức tạp, cân nhắc tách tree hoặc dùng container volume permission rõ ràng hơn.


sudo: delegation, không phải “sudo su” vĩnh viễn

/etc/sudoers/etc/sudoers.d/* định nghĩa ai được chạy lệnh nào với user nào.

Snippet an toàn hơn NOPASSWD toàn phần:

# Cho phép group ops chỉ restart một service cụ thể
%ops ALL=(root) /bin/systemctl restart nginx.service, /bin/systemctl status nginx.service

Nguy hiểm: NOPASSWD + wildcard rộng (/bin/*) + lệnh con shell escape.

# Kiểm tra cú pháp trước khi save
visudo -c

SSH key vs password trên máy chủ

  • Key-only giảm brute-force surface.
  • Passphrase trên private key là lớp bảo vệ khi laptop mất.
  • Agent forwarding (-A) tiện nhưng là vector hijack trên bastion — chỉ bật khi hiểu rõ.

Bài 10 đi sâu sshd_config — ở đây chỉ nhấn: permission của ~/.ssh/authorized_keys và home directory phải đúng (chmod 700 ~/.ssh, chmod 600 authorized_keys) nếu không sshd từ chối im lặng hoặc log một dòng dễ bỏ qua.


“Chạy app dưới root” — chi phí ẩn

  • Exploit chain trong app → root compromise ngay.
  • File tạo ra mang UID root → backup/restore và ownership nightmare.
  • Compliance thường hỏi: “process nào chạy với privilege nào?”

Pattern tốt: master process root chỉ để bind cổng <1024 rồi drop privilege (nginx làm vậy), hoặc dùng CAP_NET_BIND_SERVICE thay vì root toàn phần.


Namespace nhanh: container “root” ≠ host root

Trong container, UID 0 là root trong namespace — có thể vẫn map tới UID không đặc quyền trên host (userns). Đừng dùng kiến thức “root trong container an toàn” mà không đọc doc runtime — đặc biệt với volume mount.


Liên hệ bài trước / sau


Câu hỏi hay gặp

1. “chmod 777 có bao giờ chấp nhận được không?”
Gần như không trên host multi-user. Trong container ephemeral có người chấp nhận tạm — nhưng volume mount ra host vẫn có thể lộ permission.

2. “Tôi thấy file owned bởi UID số thay vì tên?”
User đã bị xoá khỏi passwd nhưng file vẫn giữ UID cũ — chown lại hoặc remap khi migrate.

3. “sudo -isudo -s khác gì?”
-i mô phỏng login shell (đọc profile), -s mở shell mặc định của target user — hành vi env khác nhau; cho automation, dùng sudo -u user cmd cụ thể.


Bài tiếp theo trong loạt

Phần 5: systemd — unit, service, timer — đặt dịch vụ dưới sự quản lý có log, có dependency, có restart policy.