Tại sao Permissions lại quan trọng đến vậy?

Tại sao Permissions lại quan trọng đến vậy?

Hầu hết các vụ leo thang đặc quyền (privilege escalation) trên Linux đều bắt nguồn từ một nguyên nhân đơn giản: permission được cấu hình sai. Một file có SUID b


Tại sao Permissions lại quan trọng đến vậy?

Hầu hết các vụ leo thang đặc quyền (privilege escalation) trên Linux đều bắt nguồn từ một nguyên nhân đơn giản: permission được cấu hình sai. Một file có SUID bit bật nhầm, một thư mục /tmp không có Sticky bit, một user được cấp sudo quá rộng — đó là những cái bẫy mà cả sysadmin lẫn developer thường vô tình giăng ra cho chính mình.

Bài này sẽ đi từ gốc rễ: mô hình phân quyền của Linux, cách quản lý user/group, rồi đến các “vũ khí” nâng cao như SUID/SGID/Sticky bit — những thứ mà bất kỳ ai học DevSecOps đều phải nắm chắc.

Mô hình phân quyền Linux: rwx

Linux dùng mô hình phân quyền dựa trên 3 đối tượng và 3 loại quyền:

3 đối tượng (who)

  • Owner (u) — người sở hữu file
  • Group (g) — nhóm được gán cho file
  • Others (o) — tất cả người dùng còn lại

3 loại quyền (what)

  • r (read) — đọc file / liệt kê nội dung thư mục
  • w (write) — ghi/sửa file / tạo-xóa file trong thư mục
  • x (execute) — chạy file / truy cập vào thư mục

Khi chạy ls -l, bạn sẽ thấy output dạng:

-rwxr-xr--  1 alice  devops  4096 May 27 20:00 deploy.sh

Đọc từng phần:

Ký tự Ý nghĩa
- Loại: file thường (d=thư mục, l=symlink)
rwx Owner (alice): đọc, ghi, chạy
r-x Group (devops): đọc, chạy — không ghi
r-- Others: chỉ đọc

chmod — Thay đổi quyền

Có 2 cú pháp: symbolic và octal. Dân thực chiến dùng cả hai tùy ngữ cảnh.

Symbolic mode

# Thêm quyền execute cho owner
chmod u+x script.sh

# Bỏ quyền write của others
chmod o-w config.yaml

# Gán chính xác quyền cho group
chmod g=rx deploy.sh

# Áp dụng cho tất cả (a = all: u+g+o)
chmod a+r README.md

Octal mode

Mỗi quyền là một bit: r=4, w=2, x=1. Cộng lại cho từng nhóm:

Octal Binary Permissions
7 111 rwx
6 110 rw-
5 101 r-x
4 100 r–
0 000
# 755: owner=rwx, group=r-x, others=r-x (chuẩn cho script)
chmod 755 deploy.sh

# 600: chỉ owner đọc/ghi (chuẩn cho private key SSH)
chmod 600 ~/.ssh/id_rsa

# 644: owner đọc/ghi, others chỉ đọc (chuẩn cho config file)
chmod 644 /etc/nginx/nginx.conf

# Recursive: áp dụng cho cả thư mục
chmod -R 750 /var/app/

SecOps note: Dùng find để phát hiện file có quyền quá rộng:

# Tìm file world-writable (anyone can write — nguy hiểm!)
find / -type f -perm -o+w 2>/dev/null

# Tìm thư mục world-writable
find / -type d -perm -o+w 2>/dev/null

chown & chgrp — Thay đổi sở hữu

# Đổi owner
chown alice file.txt

# Đổi cả owner lẫn group
chown alice:devops file.txt

# Chỉ đổi group
chgrp devops file.txt

# Recursive
chown -R www-data:www-data /var/www/html/

Nguyên tắc vàng: mỗi service chạy với user riêng, chỉ có quyền đọc/ghi đúng thư mục nó cần. Nginx chạy với user www-data, không cần và không nên có quyền ra ngoài /var/www/.

Users & Groups: Quản lý danh tính trên Linux

Các file quan trọng

# Thông tin user (không có password hash)
cat /etc/passwd
# Format: username:x:UID:GID:comment:home:shell
# root:x:0:0:root:/root:/bin/bash
# www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin

# Password hash (chỉ root đọc được)
cat /etc/shadow
# alice:$6$rounds=4096$salt$hash...:19500:0:99999:7:::

# Danh sách group
cat /etc/group
# Format: groupname:x:GID:members
# devops:x:1001:alice,bob

SecOps note: File /etc/shadow phải có permission 640 hoặc 000, chỉ root hoặc group shadow được đọc. Nếu file này readable bởi others — đó là một lỗ hổng nghiêm trọng.

Quản lý user

# Tạo user mới với home directory
useradd -m -s /bin/bash alice

# Tạo service account (không cần login)
useradd -r -s /usr/sbin/nologin -d /var/lib/myapp myapp

# Đặt password
passwd alice

# Sửa thông tin user
usermod -aG devops alice   # Thêm alice vào group devops
usermod -L alice           # Lock account
usermod -U alice           # Unlock account

# Xóa user (và home directory)
userdel -r alice

Quản lý group

# Tạo group
groupadd devops

# Xem user thuộc group nào
groups alice
id alice

# Xem thành viên của group
getent group devops

UID/GID đặc biệt

Range Loại
0 root — toàn quyền hệ thống
1–999 System accounts (daemon, service users)
1000+ Regular users

sudo: Ủy quyền có kiểm soát

sudo cho phép user thường chạy lệnh với quyền root (hoặc user khác) mà không cần biết password của root. Toàn bộ cấu hình nằm trong /etc/sudoerschỉ sửa bằng visudo, không bao giờ dùng text editor thường vì một lỗi cú pháp có thể khóa hệ thống.

# Mở sudoers an toàn
visudo

Cú pháp sudoers

# Cho alice toàn quyền sudo (giống root)
alice ALL=(ALL:ALL) ALL

# Cho alice chạy một số lệnh cụ thể không cần password
alice ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/journalctl

# Cho group devops sudo
%devops ALL=(ALL) ALL

# Xấu: cho phép chạy bất kỳ lệnh nào bằng NOPASSWD
alice ALL=(ALL) NOPASSWD: ALL  # <-- đừng làm vậy!

Thực hành tốt với sudo:

  • Chỉ cấp quyền sudo cho đúng lệnh cần thiết (least privilege)
  • Tránh NOPASSWD: ALL — nếu session bị chiếm, kẻ tấn công có ngay toàn quyền
  • Log sudo được ghi vào /var/log/auth.log (Ubuntu) hoặc /var/log/secure (RHEL) — đây là nguồn audit quan trọng
# Xem lịch sử sudo
grep sudo /var/log/auth.log | tail -20

su vs sudo

su sudo
Xác thực Password của target user Password của chính bạn
Audit trail Yếu — chỉ biết ai switch Mạnh — ghi từng lệnh
Granularity Toàn bộ session Từng lệnh cụ thể
Khuyến nghị Hạn chế dùng Ưu tiên dùng

SUID, SGID và Sticky Bit: Những bit đặc biệt

Ngoài rwx, Linux còn có 3 bit đặc biệt — đây cũng là nơi nhiều lỗ hổng bảo mật ẩn nấp nhất.

SUID (Set User ID) — bit s trên owner

Khi SUID được bật trên một executable, file đó chạy với quyền của owner, không phải người đang chạy nó.

# Ví dụ điển hình: /usr/bin/passwd
ls -l /usr/bin/passwd
# -rwsr-xr-x 1 root root 68208 /usr/bin/passwd
#     ^-- chữ 's' thay cho 'x' của owner = SUID

Lý do passwd cần SUID: nó phải ghi vào /etc/shadow (chỉ root mới ghi được), nhưng bất kỳ user nào cũng cần chạy được lệnh đổi password của họ.

# Bật SUID
chmod u+s /path/to/program
# hoặc octal: 4755

# Tìm tất cả file SUID trên hệ thống (SecOps audit!)
find / -perm -4000 -type f 2>/dev/null

⚠️ SecOps alert: Bất kỳ binary nào có SUID + owned by root đều là mục tiêu của kẻ tấn công. Nếu binary đó có lỗ hổng (ví dụ: buffer overflow), khai thác nó = leo thang lên root. Đây là kỹ thuật SUID exploitation cơ bản trong CTF lẫn pentest thực tế.

SGID (Set Group ID) — bit s trên group

Trên file executable: chạy với quyền của group sở hữu file.
Trên thư mục: file tạo trong thư mục sẽ kế thừa group của thư mục — rất hữu ích cho shared directories.

# Bật SGID trên thư mục dùng chung
chmod g+s /var/shared/team/
# hoặc octal: 2755

ls -ld /var/shared/team/
# drwxr-sr-x 2 root devops 4096 /var/shared/team/
#        ^-- 's' ở vị trí group execute = SGID

# Tìm file SGID
find / -perm -2000 -type f 2>/dev/null

Sticky Bit — bit t trên others

Khi Sticky bit được bật trên thư mục: chỉ owner của file mới có thể xóa file đó, dù thư mục có permission write cho all.

ls -ld /tmp
# drwxrwxrwt 10 root root 4096 /tmp
#          ^-- chữ 't' = Sticky bit

# Bật Sticky bit
chmod +t /var/shared/uploads/
# hoặc octal: 1777

Nếu /tmp không có Sticky bit — bất kỳ user nào cũng có thể xóa file của user khác trong /tmp. Đó là lý do Sticky bit là mặc định bắt buộc trên thư mục /tmp của mọi distro Linux.

Tóm tắt 3 bit đặc biệt

Bit Octal Trên file Trên thư mục
SUID 4000 Chạy với UID của owner Không có tác dụng (trên Linux)
SGID 2000 Chạy với GID của group File mới kế thừa group
Sticky 1000 Không có tác dụng Chỉ owner mới xóa được file của mình

umask — Quyền mặc định khi tạo file

umask xác định quyền bị trừ đi khi tạo file/thư mục mới. Mặc định thường là 022:

umask
# 0022

# File mới: 666 - 022 = 644 (rw-r--r--)
# Thư mục mới: 777 - 022 = 755 (rwxr-xr-x)

# Đổi umask cho session hiện tại
umask 027
# File mới: 666 - 027 = 640 (chặt hơn: group chỉ đọc, others không gì)

Để đặt umask cố định, thêm vào /etc/profile hoặc /etc/bash.bashrc. Nhiều tổ chức yêu cầu umask 027 hoặc 077 cho môi trường production.

Checklist audit nhanh — Permission hardening

# 1. File SUID/SGID (review từng cái)
find / -perm /6000 -type f 2>/dev/null | sort

# 2. File world-writable (ai cũng ghi được)
find / -perm -o+w -not -path "/proc/*" -type f 2>/dev/null

# 3. /etc/shadow permission
stat /etc/shadow | grep Access

# 4. Thư mục home có sticky bit chưa
ls -ld /home/*

# 5. User có shell login nhưng không cần thiết
grep -v nologin /etc/passwd | grep -v "false"

# 6. Ai đang có quyền sudo?
grep -E '^[^#]' /etc/sudoers /etc/sudoers.d/* 2>/dev/null
getent group sudo wheel

Tổng kết

Phân quyền Linux xây dựng trên nền tảng đơn giản — ba đối tượng, ba quyền — nhưng sức mạnh thực sự nằm ở cách kết hợp chúng: cấp đúng quyền, cho đúng người, trong đúng ngữ cảnh. Nguyên tắc least privilege không phải khái niệm trừu tượng mà là việc bạn làm mỗi ngày: chmod 600 cho private key, tạo service account với nologin, viết sudoers chỉ cấp lệnh cần thiết.

SUID/SGID/Sticky bit là lớp nâng cao cần hiểu đúng — dùng sai một bit là để lộ một cửa hậu không ai ngờ tới. Audit định kỳ bằng find -perm là thói quen bắt buộc của bất kỳ SecOps engineer nào.

Bài tiếp theo, chúng ta sẽ lên tầng trên: Processes & System Monitoring — học cách quan sát những gì đang chạy trên hệ thống, phân biệt process bình thường với process đáng ngờ, và dùng ps, top, lsof, strace như một incident responder thực thụ.

Biên Tập Viên
Biên Tập Viên

Tác giả tại Pioneer — nền tảng kiến thức thực chiến về Công nghệ & Tài chính.

Bình luận (0)

Chưa có bình luận nào. Hãy là người đầu tiên!