Bảo mật máy chủ Linux với AppArmor: Hướng dẫn tạo Profile tùy chỉnh và Sandboxing

Table of Contents

So sánh các phương pháp tiếp cận: DAC vs. SELinux vs. AppArmor

Sáu tháng trước, đội ngũ chúng tôi đã triển khai các chính sách Mandatory Access Control (MAC) trên 45 máy chủ production nhằm bảo vệ các microservice Python và Node.js khỏi những lỗ hổng zero-day. Cơ chế bảo mật truyền thống của Linux dừng lại ở Discretionary Access Control (DAC)—với quyền hạn tệp tiêu chuẩn (chmod, chown) và nhóm người dùng.

Mô hình này tồn tại một điểm mù chết người. Nếu kẻ tấn công khai thác thành công Remote Code Execution (RCE) bên trong một service account như www-data, DAC hoàn toàn không thể cô lập được chúng. Kẻ tấn công sẽ kế thừa toàn bộ quyền đọc tệp, ghi script payload vào /tmp và dò tìm các lỗ hổng kernel cục bộ.

Khi hardening các bản phân phối Linux hiện đại ở tầng MAC, có hai framework nổi bật:

SELinux (Security-Enhanced Linux): Sử dụng cơ chế gán nhãn dựa trên inode để gắn ngữ cảnh bảo mật vào tệp, tiến trình và socket. Nó chiếm ưu thế trong các môi trường RHEL, Rocky Linux và Fedora. Tuy nhiên, việc tạo chính sách SELinux từ đầu đòi hỏi phải nắm vững ngôn ngữ macro phức tạp và debug các quá trình chuyển đổi kiểu (type transitions) rắc rối.
AppArmor (Application Armor): Dựa vào kiểm soát truy cập theo đường dẫn (path-based access control) bằng cách liên kết trực tiếp profile bảo mật với các đường dẫn tệp thực thi như /usr/bin/nginx hoặc /opt/api/server. Các profile là tệp văn bản thuần túy, dễ kiểm tra và được lưu tại /etc/apparmor.d/.

Đối với môi trường Debian và Ubuntu, AppArmor mang lại giải pháp nhanh nhất để cô lập daemon mà không cần cả một đội ngũ bảo mật chuyên trách chỉ để biên dịch chính sách.

Ưu và nhược điểm: 6 tháng trên Production

Vận hành AppArmor trên các node production có lưu lượng truy cập cao đem lại khả năng cô lập vững chắc, bên cạnh một vài đặc điểm vận hành đáng lưu ý.

Ưu điểm

Quy tắc dễ đọc (Human-Readable Rules): Các quy tắc sử dụng globbing tiêu chuẩn cùng các cờ quyền tường minh như r (read), w (write) và ix (inherit execute). Bất kỳ kỹ sư nào quen thuộc với shell wildcard đều có thể audit profile trong vài phút.
Chế độ học tương tác (Interactive Learning Mode): Các tiện ích như aa-genprof và aa-logprof phân tích log kiểm toán và hiển thị các prompt tương tác để phê duyệt, từ chối hoặc gom nhóm wildcard các đường dẫn truy cập được phát hiện trong quá trình chạy thực tế.
Sandboxing không tốn tài nguyên (Zero-Overhead Sandboxing): AppArmor gắn trực tiếp vào Linux Security Modules (LSM) bên trong kernel. Trong các benchmark mô phỏng ở mức 50.000 requests/giây với wrk, độ trễ tăng thêm vẫn ở mức dưới 0,8% mà không làm tăng dung lượng bộ nhớ đo lường được.

Nhược điểm

Nhạy cảm với đường dẫn (Path Sensitivity): Do AppArmor nhắm vào các đường dẫn tuyệt đối, các liên kết mềm (symbolic link), việc đổi tên binary, liên kết cứng (hard link) hoặc môi trường chroot không được định tuyến có thể vượt qua hoặc làm hỏng quá trình khớp profile nếu không được khai báo từ trước.
Không lọc mạng tầng L3/L4: AppArmor giới hạn các nhóm giao thức—chẳng hạn cho phép tcp trong khi chặn các raw packet socket—nhưng không thể lọc theo địa chỉ IP hoặc port đích. Bạn vẫn cần nftables hoặc iptables để lọc gói tin.

Cấu hình khuyến nghị

Để thiết lập quy trình sandboxing ổn định trên Ubuntu 22.04 hoặc Debian 12, hãy cài đặt các công cụ cốt lõi và kích hoạt kernel audit daemon:

# Cài đặt các tiện ích AppArmor và audit daemon
sudo apt update
sudo apt install -y apparmor apparmor-utils auditd

# Kiểm tra trạng thái kernel module AppArmor
sudo aa-status

Tuyệt đối không đưa profile chưa được kiểm thử trực tiếp vào chế độ enforce mode. Các chính sách quá chặt chẽ thường làm gián đoạn tác vụ xoay vòng log nền lúc 3 giờ sáng, làm chết các probe health check hoặc chặn việc tạo tệp tạm. Hãy chạy các profile mới ở complain mode ít nhất 48 đến 72 giờ dưới lưu lượng truy cập bình thường trước khi chuyển sang enforce.

Hướng dẫn triển khai: Tạo Profile AppArmor tùy chỉnh

Xét một kịch bản triển khai thực tế: sandbox một worker FastAPI tùy chỉnh đặt tại /opt/api/server.py. Ứng dụng cần đọc cấu hình JSON, bind vào TCP socket và ghi vào thư mục log. Ứng dụng tuyệt đối không được truy cập /etc/shadow, xem thư mục home của người dùng hoặc mở các interactive shell.

Bước 1: Xác định Stub cho ứng dụng

Đảm bảo dịch vụ chạy thông qua một script entrypoint cố định, ví dụ như /usr/local/bin/myapi:

sudo chmod +x /usr/local/bin/myapi

Bước 2: Khởi tạo Profile bằng aa-genprof

Khởi chạy công cụ tạo profile ở chế độ complain mode để theo dõi các sự kiện kernel audit:

sudo aa-genprof /usr/local/bin/myapi

Giữ phiên terminal đó hoạt động. Trong một session khác, hãy kích hoạt các luồng công việc thông thường của ứng dụng: gửi payload HTTP thực tế, chạy test suite, xoay vòng log và thực thi các tác vụ chạy ngầm. AppArmor sẽ bắt mọi system call và ghi lại các đường dẫn được yêu cầu vào /var/log/audit/audit.log.

Bước 3: Xem xét và kiểm tra cú pháp Profile

Quay lại session aa-genprof và nhấn S để quét log kiểm toán. Tiện ích sẽ hiển thị các prompt tương tác để cho phép, từ chối hoặc gom nhóm wildcard các đường dẫn tệp ghi nhận được. Tệp cấu hình kết quả sẽ được lưu tại /etc/apparmor.d/usr.local.bin.myapi.

Dưới đây là một profile hoàn chỉnh, đã được siết chặt bảo mật và sẵn sàng cho production:

# /etc/apparmor.d/usr.local.bin.myapi
#include <tunables/global>

/usr/local/bin/myapi {
  # Các abstraction cơ bản
  #include <abstractions/base>
  #include <abstractions/python>
  #include <abstractions/nameservice>

  # Quyền truy cập mạng
  network inet tcp,
  network inet udp,

  # Trình thông dịch và entrypoint
  /usr/bin/python3* ix,
  /usr/local/bin/myapi r,

  # Mã nguồn ứng dụng và cấu hình
  /opt/api/ r,
  /opt/api/** r,
  /opt/api/config.json r,

  # Ghi log và bộ lưu trữ runtime tạm thời
  /var/log/myapi/ w,
  /var/log/myapi/** rw,
  /tmp/myapi_*.tmp rw,

  # Chặn hoàn toàn các đường dẫn nhạy cảm và khởi tạo shell
  deny /etc/shadow* rwklx,
  deny /etc/gshadow* rwklx,
  deny /root/** rwklx,
  deny /home/** rwklx,
  deny /bin/dash rx,
  deny /bin/bash rx,
  deny /usr/bin/sh rx,
}

Bước 4: Tải lại và kích hoạt chế độ Enforce cho Profile

Biên dịch các quy tắc vừa cập nhật trực tiếp vào kernel và kích hoạt chế độ thực thi nghiêm ngặt:

# Phân tích cú pháp và tải lại các quy tắc profile
sudo apparmor_parser -r /etc/apparmor.d/usr.local.bin.myapi

# Chuyển profile sang enforce mode
sudo aa-enforce /usr/local/bin/myapi

# Kiểm tra trạng thái thực thi đang hoạt động
sudo aa-status | grep myapi

Bước 5: Kiểm thử Sandboxing và khả năng cô lập

Xác thực sandbox đã chặn thành công di chuyển ngang bằng cách thử thực hiện các thao tác trái phép từ bên trong ngữ cảnh ứng dụng:

# Kiểm tra log kernel để tìm các truy cập bị từ chối
sudo dmesg | grep -i "apparmor.*denied"

# Hoặc truy vấn các từ chối AVC gần đây qua auditd
sudo ausearch -m AVC -ts recent

Nếu kẻ tấn công khai thác lỗ hổng RCE, mọi nỗ lực khởi chạy /bin/bash hoặc truy cập các thư mục nhạy cảm sẽ ngay lập tức kích hoạt lỗi EACCES (Permission Denied) ở cấp độ kernel. Cuộc tấn công bị chặn đứng ngay lập tức, để lại dấu vết kiểm toán mà không làm lộ thông tin xác thực root.