- Landlock là API bảo mật của Linux cho phép ứng dụng khai báo rõ ràng các tài nguyên mà nó có thể truy cập, từ đó thực hiện tự sandboxing ở cấp độ kernel
- Đơn giản hơn SELinux hay AppArmor, và có thể tạo cũng như áp dụng chính sách trong lúc chạy mà không cần đặc quyền của nhà phát triển
- Chính sách được định nghĩa dưới dạng allowlist rõ ràng cho các tệp, thư mục, cổng... được phép truy cập, đồng thời có thể tăng cường bảo mật dần dần thông qua hạn chế phân tầng
- Có binding cho Rust, Go, Haskell..., cho phép triển khai kiểm soát truy cập chi tiết trong nhiều môi trường khác nhau như ứng dụng GUI, máy chủ, tiến trình desktop
- Trong hệ sinh thái bảo mật Linux, đây đang được chú ý như một công cụ sandbox không đặc quyền đơn giản và thực dụng, đồng thời là thành phần then chốt tiềm năng để tăng cường bảo mật desktop trong tương lai
Tổng quan về Landlock
- Landlock là một API buộc ứng dụng Linux phải khai báo rõ ràng các tài nguyên mà chính nó có thể truy cập
- Tương tự ý tưởng
unveil() và pledge() của OpenBSD, dựa trên nguyên tắc “chỉ cho phép tài nguyên cần thiết, còn lại đều chặn”
- Cung cấp một lớp phòng vệ thân thiện với nhà phát triển dễ hiểu và dễ tích hợp hơn các cơ chế bảo mật Linux truyền thống
- Mục tiêu là cung cấp một phần giới thiệu dễ tiếp cận và khuyến khích sử dụng Landlock
Cách hoạt động
- Tồn tại dưới dạng Linux Security Module(LSM) và có thể sử dụng từ Linux 5.13
- Khác với SELinux hay AppArmor, Landlock áp dụng hạn chế tạm thời theo từng tiến trình (transient restriction)
- Chính sách được tạo lúc runtime, chỉ áp dụng cho luồng hiện tại và các tiến trình con, rồi biến mất khi tiến trình kết thúc
- Thành phần của chính sách
- Handled accesses: các nhóm thao tác cần hạn chế (ví dụ: đọc/ghi hệ thống tệp)
- Access grants: danh sách rõ ràng các đối tượng được phép
- Ví dụ chính sách
/home/user chỉ đọc/tmp đọc/ghi- cho phép bind cổng
2222
- Khi gọi
landlock_restrict_self(), luồng tương ứng và các tiến trình con sẽ vĩnh viễn đi vào vùng bị hạn chế
- Hạn chế không thể gỡ bỏ, và có thể lồng tối đa 16 lớp (layer)
- Lớp bên dưới có thể tiếp tục thu hẹp quyền truy cập, nhưng quyền đã bị loại bỏ ở lớp trên thì không thể khôi phục
- Hoạt động theo cách không đặc quyền (unprivileged), nên cả ứng dụng thông thường cũng có thể tự sandbox
- Thông qua quản lý phiên bản ABI, nó vẫn có thể hoạt động trong phạm vi cho phép trên các kernel cũ hơn
- Là Stackable LSM, nên có thể dùng song song với SELinux hoặc AppArmor
Vì sao nên dùng
- Phù hợp với các ứng dụng có mẫu truy cập tệp có thể dự đoán được
- Ví dụ: giới hạn web server chỉ được truy cập
/var/www/html và /tmp
- Không cần quản trị viên can thiệp hay cấu hình toàn hệ thống, có thể định nghĩa chính sách trực tiếp trong mã nguồn
- Có thể dùng mà không cần leo thang đặc quyền, nên dễ tích hợp vào phần lớn chương trình
- Có binding cho Rust, Go, Haskell và cũng có nhiều dự án wrapper theo phong cách
unveil
- Hiện chưa có thư viện C chính thức, nhưng đã có nhiều triển khai không chính thức có thể sử dụng
- Trong ví dụ Rust,
/usr, /etc, /dev được đặt ở chế độ chỉ đọc, còn /home, /tmp được cho phép đọc/ghi
Thực trạng và nhu cầu sandboxing trên Linux
- Khi việc sử dụng Linux tăng lên, malware nhắm vào desktop cũng gia tăng
- Mức độ an toàn tương đối của Linux đến từ thị phần và rào cản kỹ thuật, chứ không hẳn vì bản thân cấu trúc vốn an toàn hơn
- Vấn đề của các bản phân phối thông thường
- Có thể chạy các binary không đáng tin cậy
- Có thể chạy trực tiếp script từ Internet
- Dùng sudo không cần mật khẩu
- Ứng dụng thông thường có thể truy cập các tệp nhạy cảm trong
$HOME
- Trong môi trường X11 có thể theo dõi thao tác gõ phím
- Có thể bind cổng tùy ý
Giới hạn của các công cụ bảo mật hiện có
- Containerization (Docker, Podman): phù hợp để cô lập dịch vụ nhưng không phù hợp với ứng dụng desktop, và đã có trường hợp vô hiệu hóa cách ly bằng tùy chọn
--privileged
- Flatpak / Snap: phù hợp với ứng dụng GUI nhưng phạm vi quyền quá rộng, không phù hợp với công cụ CLI
- Firejail: cần profile theo từng ứng dụng, và phải gọi rõ ràng mỗi lần chạy
Các cơ chế hiện có từ góc nhìn nhà phát triển
- seccomp: mạnh nhưng cấu hình phức tạp, và cách làm blacklist thì mong manh
- SELinux: mạnh nhưng phức tạp và cần chính sách từ quản trị viên; nhiều bản phân phối mặc định tắt
- AppArmor: đơn giản hơn SELinux nhưng vẫn cần profile do quản trị viên tạo, và cũng bị tắt trên một số bản phân phối
Tóm tắt ưu điểm của Landlock
- Không đặc quyền, lấy ứng dụng làm trung tâm, dễ tích hợp, chặn mặc định (deny-by-default)
- Được hỗ trợ rộng rãi từ Linux 5.13 trở đi, đồng thời duy trì tương thích ngược và xuôi
- Dù chưa hoàn hảo, Landlock vẫn lấp vào khoảng trống với vai trò công cụ sandbox không đặc quyền đơn giản và độc lập
Khả năng ứng dụng của Landlock
- Với các tiến trình daemon đặc quyền cao chạy lâu dài, có thể dùng Landlock để giới hạn phạm vi truy cập
- Trình đọc PDF, trình xem ảnh, trình duyệt web, trình xử lý văn bản... có thể bị giới hạn chỉ truy cập các tệp đang mở
- Máy chủ FTP/HTTP có thể được cấu hình để chỉ truy cập các tệp cần thiết
- Ví dụ: ngay cả khi nginx đang chạy bằng root, kẻ tấn công có chiếm được shell cũng không thể truy cập các tệp ngoài chính sách
- Nếu đề xuất Supervisor được đưa vào, có thể triển khai hệ thống quyền kiểu Android trên desktop Linux
- Khi kết hợp với GUI và hệ thống lưu quyền, có thể mang lại trải nghiệm người dùng an toàn hơn
Các tính năng Landlock đang được phát triển
- Supervise Mode: quyết định tương tác trong user space về việc cho phép/từ chối truy cập, tương tự prompt quyền kiểu Android
- Socket Restrictions: kiểm soát chi tiết loại socket và cổng mà tiến trình có thể sử dụng
- LANDLOCK_RESTRICT_SELF_TSYNC: lan truyền hạn chế sang mọi luồng trong tiến trình
- LANDLOCK_ADD_RULE_QUIET: ức chế thông báo log audit cho một số đối tượng nhất định
- LANDLOCK_ADD_RULE_NO_INHERIT: ngăn quyền của thư mục cha được kế thừa xuống bên dưới, giúp kiểm soát hệ thống tệp chi tiết hơn
Tóm tắt
- Landlock là một cơ chế sandbox chặn theo mặc định đơn giản và dựa trên mô hình không đặc quyền
- Dễ hiểu, dễ tích hợp và có tiềm năng lớn trong việc cải thiện bảo mật cho ứng dụng và desktop Linux
- Nhà phát triển có thể áp dụng Landlock trực tiếp vào ứng dụng để nâng cao mức độ bảo mật
1 bình luận
Ý kiến trên Hacker News
Tôi viết một chương trình đơn giản bằng C để chỉ cho phép lắng nghe trên đúng một cổng cụ thể, và chặn toàn bộ các kết nối mạng còn lại
Tôi tham khảo
sandboxer.cmẫu, và chỉ kiểm soát mạng chứ không đụng đến giới hạn truy cập tệpCác kết nối bị chặn hiện ra trong
dmesg, có lẽ là nhờ tính năng auditCông cụ này hoạt động ở chế độ người dùng không đặc quyền, và cũng chạy tốt bên trong container mà không cần cấu hình tường lửa
Tuy vậy, tôi không nghĩ nó phù hợp để ngăn chặn hoàn toàn các chương trình độc hại
Xem issue #28 và chuỗi mail liên quan, có một vấn đề là quy tắc sandbox không thể tham chiếu tới thư mục chưa tồn tại
Ví dụ, nếu thêm quy tắc khi
~/.sshchưa tồn tại, thì sau này dù thư mục được tạo ra, quyền truy cập cũng sẽ không bị chặnNghĩa là về mặt bảo mật có thể phát sinh lỗ hổng
Chạy với đặc quyền tối thiểu hóa ra khá rắc rối
“Microlandia” không chạy được, nhưng các game Unity khác thì hoạt động tốt
Tôi hy vọng sẽ có thêm nhiều công cụ dựa trên Landlock để việc này trở nên dễ dàng hơn
Có vẻ các CRI đang cố định nghĩa giao diện riêng của họ, nhưng chắc chắn lúc nào cũng sẽ chậm hơn hỗ trợ từ kernel
Tôi không nghĩ phần lớn người phụ trách hạ tầng sẽ bảo trì chính sách sandbox theo từng ứng dụng
Theo tôi, việc ứng dụng tự dùng Landlock sẽ thực tế hơn
họ giải thích rằng nếu runtime chỉ đơn giản cho phép system call đi qua, thì sẽ phát sinh vấn đề phải tin tưởng ứng dụng tự khóa chính nó
Nội bộ chúng tôi cũng đang dùng một API tương tự để quản lý các tiến trình quan trọng
Kiểu nghiên cứu như vậy sẽ rất hữu ích cả với các ngành bị quản lý chặt
Nếu là tính năng kernel thì đáng ra C API phải có trước chứ, nên tôi thắc mắc vì sao lại không có
libc chỉ là một lớp nằm bên trên, và đến giờ vẫn còn nhiều syscall tồn tại mà không có wrapper trong libc
Bạn cũng có thể tự tạo header và gọi bằng macro
_syscallNChỉ cần dùng wrapper đơn giản như landbox,
còn Rust hay Go cũng có thể lộ ra C FFI
Chỉ cần tham khảo ví dụ sandboxer.c của kernel là đủ
Nó khác Landlock nhưng có thể dùng bổ sung cho nhau
/sysCó lẽ là do nguyên tắc không đặc quyền
Tôi cũng tò mò liệu có thể chặn syscall của Landlock bằng seccomp không
Nếu một chính sách seccomp cũ không chứa số hiệu của Landlock, liệu có thể gây SIGSYS không?
API dựa trên filesystem có quá nhiều footgun, còn kiểm soát truy cập dựa trên dirfd thì syscall phù hợp hơn
Một bộ lọc seccomp được viết cẩn thận sẽ trả về -ENOSYS để nó chỉ trông như “không được hỗ trợ”
Vì Landlock chỉ tiếp tục siết chặt quyền hiện có, chứ không cấp thêm quyền mới
Tôi đang chuẩn bị rời macOS để chuyển hẳn sang Linux, và muốn biết Landlock có giúp gì cho phòng chống malware không
Ví dụ, tôi muốn tạo một môi trường tự động từ chối truy cập vào
~/.sshNgoài ra, tôi cũng muốn biết liệu có thể dùng nó để làm app launcher hay không
Mục đích là để ứng dụng tự hạn chế những quyền không cần thiết, nhờ đó kẻ tấn công không thể chiếm toàn bộ hệ thống
~/.sshcần mô hình MAC như AppArmor hoặc SELinuxLandlock hữu ích khi ứng dụng tự giới hạn chính nó hoặc các tiến trình con
Ví dụ như npm chỉ giới hạn script post-install trong thư mục build
Đây là API để chính nhà phát triển ứng dụng dùng, giống pledge của OpenBSD
Tuy nhiên Linux có hệ sinh thái phân tán nên việc áp dụng sẽ chậm
Trong thời gian đó, dùng theo kiểu wrapper hoặc launcher sẽ thực tế hơn
Rốt cuộc, nó chỉ hiệu quả khi chương trình biết rõ quyền của chính mình
Ứng dụng chỉ định whitelist cho các tài nguyên cần dùng ở giai đoạn đầu chạy, rồi chặn mọi thứ còn lại
Nó không nhằm chống phần mềm độc hại, mà là để tự bảo vệ tiến trình của chính nó
Trong thư viện tiêu chuẩn đã có syscall rồi, vậy có thực sự cần một thư viện riêng không?
tài liệu man7 cũng đã có
Tôi tự hỏi liệu họ chỉ đang muốn một lớp trừu tượng hóa hay không
nên khá bất ngờ khi glibc vẫn chưa cung cấp giao diện Landlock
Có lẽ là vì vấn đề tương thích ngoài Linux