Đừng để lỗi Permission Denied đánh lừa bạn
Sau 2 năm dùng Fedora làm máy dev chính, mình cực kỳ ưng độ ổn định của nó. Thế nhưng, dám cá là ai mới chuyển từ Ubuntu sang cũng từng phát điên vì kịch bản này: Bạn cài Nginx, chmod 755 đủ kiểu, cấu hình chuẩn đét nhưng truy cập vẫn dính 403 Forbidden. Mở log ra, dòng chữ AVC denied hiện lên như một lời thách thức.
90% các bài hướng dẫn trên mạng sẽ bảo bạn: “Chạy setenforce 0 đi cho nhanh”. Đừng nghe họ! Đó là cách làm cực kỳ thiếu chuyên nghiệp, giống như việc bạn tháo sạch ổ khóa cửa chỉ vì chìa khóa hơi rít. Thay vì tắt bảo mật, hãy học cách “thương lượng” để SELinux hiểu ý bạn.
Giải mã “cơn ác mộng” AVC denied
Hãy coi SELinux là một lớp bảo vệ nghiêm ngặt hoạt động theo cơ chế Mandatory Access Control (MAC). Nó không quan tâm bạn có quyền root hay không. Chỉ cần nhãn (label) của tiến trình (process) và file không khớp, nó sẽ chặn đứng hành động đó ngay lập tức để phòng ngừa rủi ro. Sự kiện này được ghi lại dưới dạng log AVC denied.
Trước khi bắt đầu, hãy chắc chắn hệ thống của bạn đang bật chế độ bảo vệ:
sestatus
Nếu thấy Current mode: enforcing, bạn đang đi đúng hướng rồi đấy.
Dùng setroubleshoot để “dịch” log sang tiếng người
File log thô tại /var/log/audit/audit.log thực sự là một mớ hỗn độn khó nuốt. May mắn là Fedora có sẵn setroubleshoot – công cụ giúp chuyển đổi đống code loằng ngoằng đó thành những gợi ý dễ hiểu.
Cài đặt công cụ hỗ trợ
Nếu bạn dùng bản Server hoặc Minimal, hãy bổ sung nó bằng lệnh:
sudo dnf install setroubleshoot-server -y
Truy tìm nguyên nhân với sealert
Giả sử Nginx của bạn không khởi động được. Thay vì đoán mò, hãy yêu cầu hệ thống giải trình về các lỗi xảy ra trong 1 giờ qua:
sudo journalctl -t setroubleshoot --since "1 hour ago"
Muốn chi tiết hơn? Hãy copy mã ID lỗi từ log và chạy:
sudo sealert -l [MÃ_ID_CỦA_LỖI]
Lúc này, sealert sẽ chỉ rõ: Cái gì bị chặn? Tại sao? Thậm chí nó còn đưa ra cả câu lệnh để bạn copy-paste và sửa lỗi trong 30 giây.
Sửa lỗi bằng cách gán lại nhãn (Labeling)
Lỗi SELinux phổ biến nhất là do bạn di chuyển file. Ví dụ, bạn kéo code từ /home/user/project sang /var/www/html. File lúc này vẫn mang nhãn của thư mục Home, khiến Nginx không thể chạm vào.
Thay vì tắt SELinux, hãy dạy cho nó biết đây là dữ liệu web hợp lệ:
# Đăng ký nhãn cho đường dẫn mới
sudo semanage fcontext -a -t httpd_sys_content_t "/my/custom/path(/.*)?"
# Áp dụng thay đổi thực tế lên file
sudo restorecon -Rv /my/custom/path
Lệnh này giúp hệ thống hiểu rằng mọi thứ trong thư mục đó đều thuộc về web server. An toàn và cực kỳ sạch sẽ!
Tạo Custom Policy khi mọi cách đều thất bại
Đôi khi ứng dụng của bạn chạy ở những port lạ hoặc thực hiện các hành vi đặc thù mà nhãn tiêu chuẩn không hỗ trợ. Đây là lúc audit2allow tỏa sáng.
Giả sử bạn có một script Python cần ghi log vào thư mục hệ thống và liên tục bị chặn. Hãy làm theo 3 bước sau:
1. Trích xuất lỗi từ log
Lọc các sự kiện bị chặn liên quan đến Python và chuyển nó thành một file định nghĩa chính sách (.te):
sudo ausearch -c "python3" --raw | audit2allow -m my_python_script > my_python_script.te
2. Kiểm tra nội dung chính sách
Mở file .te vừa tạo. Bạn sẽ thấy một cấu trúc cho phép quyền truy cập cụ thể. Ví dụ:
allow httpd_t user_home_t:file { write create };
Hãy đọc kỹ để đảm bảo bạn không vô tình cấp quyền quá đà cho ứng dụng.
3. Kích hoạt chính sách mới
Nếu mọi thứ ổn, hãy biên dịch và nạp nó vào nhân Linux:
checkmodule -M -m -o my_python_script.mod my_python_script.te
semodule_package -o my_python_script.pp -m my_python_script.mod
sudo semodule -i my_python_script.pp
Xong! Ứng dụng của bạn giờ đã chạy mượt mà mà không cần hạ thấp hàng rào bảo mật của hệ thống.
Mẹo debug nhanh
Nếu bạn phân vân không biết lỗi do code hay do SELinux, hãy tạm thời chuyển sang chế độ Permissive:
sudo setenforce 0
Ở chế độ này, SELinux chỉ đứng nhìn và ghi log chứ không chặn. Nếu ứng dụng chạy được, đích thị là lỗi nhãn. Sau khi test xong, hãy nhớ bật lại ngay bằng sudo setenforce 1 để giữ an toàn.
Lời kết
Làm chủ SELinux giúp bạn nâng tầm từ một người biết cài cắm thành một kỹ sư hệ thống thực thụ. Chỉ cần 5 phút dùng audit2allow, bạn đã bảo vệ server khỏi hàng tá rủi ro bảo mật tiềm tàng. Đừng chọn cách dễ nhất, hãy chọn cách chuyên nghiệp nhất!

