(TIỂU LUẬN) báo cáo bài tập lớn AN TOÀN hệ điều HÀNH đề tài AN TOÀN hệ điều HÀNH LINUX

LINUX SECURITY MODULES

LỊCH SỬ LSM

Vào cuối những năm 1990, hệ điều hành Linux đã có được sự hỗ trợ cần thiết để biến nó trở thành một thứ có thể thay thế trong thị trường hệ thống UNIX Mặc dù có nhiều biến thể UNIX, chẳng hạn như AIX và HP / UNIX, và thậm chí cả các hệ thống mã nguồn mở khác, chẳng hạn như các biến thể BSD, Linux đã trở thành nhà lãnh đạo chia sẻ tư duy giữa các hệ thống UNIX Các nhà cung cấp máy chủ lớn, chẳng hạn như IBM và HP, đã hỗ trợ đằng sau Linux, và nó nhanh chóng trở thành đối thủ cạnh tranh chính của Microsoft Windows.

Ngoài ra, vào cuối những năm 1990, một số dự án đã xuất hiện nhằm trang bị thêm các tính năng bảo mật khác nhau vào nhân Linux Vì Linux là mã nguồn mở nên bất kỳ ai cũng có thể sửa đổi nó để đáp ứng yêu cầu của họ(miễn là họ phát hành mã nguồn của mình trở lại cộng đồng, theo yêu cầu của Giấy phép Công cộng GNU [112]) Một loạt các hệ thống nguyên mẫu đã xuất hiện, bao gồm Argus PitBull [13], LIDS [183], AppArmor (ban đầu được gọi là Subdomain) [228], RSBAC [240], GRSecurity [296], DTE (xem Chương 7) cho Linux [127], Medusa DS9 [204], OpenWall [236], Phần mềm Hệ điều hành Bảo mật của HP dành cho Linux [ 80], và trang bị thêm của hệ thống Flask / DTOS / DTMach trước đây (xem Chương 7), hiện được gọi là SELinux Tất cả các hệ thống Linux đã sửa đổi này khác nhau theo những cách cơ bản, nhưng tất cả đều nhằm mục đích cung cấp một chức năng bảo mật. AppArmor và PitBull đều được bán dưới dạng sản phẩm thương mại.

Năm 2001, nỗ lực phát triển cho việc đưa bộ giám sát chuẩn vào nhân Linux. Các vấn đề về worm , vi rút và các cuộc tấn công từ chối dịch vụ đã đạt đến mức đáng lo, mặc dù chủ yếu trên nền tảng Windows Tại hội nghị thượng đỉnh về nhân Linux năm đó, SELinux nguyên mẫu đã được trình bày, và cộng đồng Linux bao gồm cả Linus Torvalds nói riêng, dường như đã chấp nhận ý kiến rằng bộ giám sát chuẩn là cần thiết Tuy nhiên, Linus phải đối mặt với hai thách thức Đầu tiên, ông không phải là một chuyên gia bảo mật, vì vậy ông không thể dễ dàng quyết định giữa các phương pháp tiếp cận và cảm thấy nó không thích hợp để ông đưa ra quyết định như vậy Thứ hai, bản thân cộng đồng bảo mật không thể đồng ý trên một phương pháp duy nhất và

"tốt nhất", vì vậy Linus không thể phụ thuộc vào cộng đồng bảo mật để định hướng cho một cách tiếp cận duy nhất Kết quả là Linus đồng ý với một thiết kế dựa trên các mô- đun nhân trong đó một giao diện có thể hỗ trợ tất cả các mô-đun cần thiết Cách tiếp cận này đã trở thành khung LSM.

Một cộng đồng được hình thành xung quanh ý tưởng xây dựng một giao diện bộ giám sát chuẩn duy nhất cho Linux (mặc dù không phải tất cả các nhà nghiên cứu nguyên mẫu bảo mật Linux đều đồng ý [239, 297] 1), và cộng đồng đã thiết kế và triển khai khung LSM Nhiệm vụ chính là thực hiện Giao diện bộ giám sát chuẩn LSM Thiết kế của giao diện bộ giám sát chuẩn của khung LSM với các mục tiêu sau [342]:

• Giao diện bộ giám sát chuẩn phải thực sự thống nhất, sao cho “sử dụng một mô-đun bảo mật khác chỉ là vấn đề tải một mô-đun hạt nhân khác ”

• Các giao diện bộ giám sát chuẩn phải “đơn giản về mặt khái niệm, xâm lấn tối thiểu và hiệu quả”

• Phải hỗ trợ cơ chế khả năng POSIX.1e như một “mô-đun bảo mật tùy chọn”

Hai yêu cầu đầu tiên thúc đẩy việc thu thập kết hợp các truy vấn ủy quyền từtất cả về bảo mật Linux trước đó, như vậy tất cả các mô-đun có thể được hỗ trợ, nhưng hạn chế số lượng truy vấn ủy quyền nhiều nhất có thể để ngăn chặn các ủy quyền thừa, đã làm tăng thêm độ phức tạp và tác động đến hiệu suất Mặc dù giao diện LSM được thiết kế thủ công [342], các công cụ phân tích mã nguồn được xây dựng để xác minh tính đầy đủ [351] và tính nhất quán [149] của giao diện LSM, đã tìm thấy sáu lỗi giao diện và đã được giải quyết.

Phân tích hiệu suất cho thấy hầu hết giao diện LSM không có tác động lên hiệu suất một cách rõ ràng [342], nhưng việc triển khai CIPSO (tức là mạng được gắn nhãn, xem Phần 7.5.2) được cung cấp với giao diện LSM ban đầu đã bị từ chối Hiệu suất bị hao tổn cho việc giữ các nhãn nhất quán dưới phân mảnh và chống phân mảnh gói, ngay cả khi không có chính sách bảo mật nào được thực thi, điều này quá tốn kém Có hai lựa chọn thay thế khác cho mạng được gắn nhãn hiện được hỗ trợ bởi hạt nhâ Linux Đầu tiên là Labeled IPsec[148], dựa trên mạng có gắn nhãn Flask [50], thương lượng nhãn cho giao tiếp mạng IPsec ngoài những tham số mật mã Mạng điều khiển LSM giao tiếp bằng cách cho phép một quá trình có thể sử dụng một kênh giao tiếp IPsec cụ thể hay không Vì nhãn của kênh IPsec được thiết lập tại thời điểm thương lượng, nên không cần bao gồm nhãn trong gói Thứ hai, Paul Moore đã xây dựng một triển khai mới của CIPSO cho Linux, được gọi là Netlabel [214] Netlabel cung cấp phiên bản CIPSO ít xâm nhập hơn đã được chấp nhận bởi cộng đồng Linux.

Khung mô-đun bảo mật Linux chính thức được thêm vào nhân Linux với việc phát hành phiên bản 2.6 Mô-đun SELinux và một mô-đun để triển khai các tính năng POSIX [307] đã được bao gồm trong việc phát hành LSM Novell, nhà phân phối của SuSE Linux, đã mua công ty hỗ trợ AppArmor, vì vậy SuSE và các bản phân phối Linux khác cũng hỗ trợ AppArmor LSM.

SELinux và AppArmor đã trở thành những LSM quan trọng Trong khi cả hai đều mang đến cho Linux một sự cải tiến bảo mật, chuyển đổi Linux (hoặc bất kỳ hệ thống UNIX nào) thành một hệ thống có thể đáp ứng tham chiếu giám sát an toàn là một nhiệm vụ khó khăn Tuy nhiên, với việc Linus tái khẳng định sự ủng hộ của mình đối với LSM framework [188] vào năm 2006 và nhiều nhà cung cấp của Linux hỗ trợ đằng sau LSM, khung LSM có thể được coi là một thành công khá khiêm tốn.

TRIỂN KHAI LSM

Việc triển khai khung LSM bao gồm ba phần: (1) định nghĩa giao diện bộ giám sát chuẩn; (2) vị trí giao diện bộ giám sát chuẩn; và (3) bản thân việc triển khai bộ giám sát chuẩn. Định nghĩa giao diện bộ giám sát chuẩn LSM Định nghĩa giao diện LSM xác định các cách mà nhân Linux có thể gọi bộ giám sát chuẩn LSM Tệp tiêu đề Linux include/linux/security.h liệt kê một tập hợp các con trỏ hàm gọi các hàm trong LSM được tải Một cấu trúc duy nhất, được gọi là security_operations , chứa tất cả các con trỏ hàm LSM Chúng tôi gọi chung các con trỏ chức năng này là các móc LSM Về cơ bản, các móc LSM tương ứng với các truy vấn ủy quyền LSM, nhưng giao diện LSM cũng phải bao gồm các móc LSM cho các tác vụ LSM khác, chẳng hạn như ghi nhãn, chuyển tiếp và duy trì nhãn.

Hai ví dụ về móc LSM được thể hiện bên dưới. static inline int security_inode_create (struct inode *dir, struct dentry *dentry, int mode)

{ if (unlikely (IS_PRIVATE (dir))) return 0; return security_ops->inode_create (dir, dentry, mode); } static inline int security_file_fcntl (struct file *file, unsigned int cmd, unsigned long arg)

{ return security_ops->file_fcntl (file, cmd, arg);

} Đầu tiên, security_inode_create cho phép liệu một quy trình có được LSM cho phép tạo một tệp mới hay không, được xác định bởi dentry, trong một thư mục dir cụ thể Móc LSM được gọi thông qua lệnh gọi đến con trỏ hàm được xác định bởi security_ops-> inode_create LSM được tải xác định cách ủy quyền được thực hiện. Thứ hai, security_file_fcntl cho phép khả năng của một quy trình cụ thể để gọi fcntl trên một tệp cụ thể Các móc LSM tiếp theo trong hàm do_fcntl cho phép LSM giới hạn một số cách sử dụng fcntl một cách độc lập (ví dụ: thiết lập trường fower báo hiệu quá trình liên quan trên các hoạt động trên file).

Tất cả có hơn 150 móc LSM cho phép ủy quyền (như trên) và các hoạt động LSM khác của nhãn, chuyển đổi nhãn và bảo trì nhãn Mặc dù các móc LSM khác nhau nhằm phục vụ các mục đích khác nhau, chúng đều có định dạng tương tự như hai định dạng được liệt kê ở trên.

Vị trí giao diện bộ giám sát chuẩn LSM Thách thức chính trong việc thiết kế khung LSM là vị trí của móc LSM Hầu hết các móc LSM được liên kết với một lệnh gọi hệ thống, vì vậy những móc LSM được đặt ở đầu vào lệnh gọi hệ thống Tuy nhiên, một số không thể đặt móc LSM tại điểm nhập lệnh gọi của hệ thống (ví dụ: để ngăn cách tấn công TOCTTOU, xem Chương 2) Ví dụ, như trong Hình 9.1, lệnh gọi hệ thống open chuyển đổi một tệp đường dẫn đến bộ mô tả tệp cho phép truy cập (tức là đọc và/hoặc ghi) vào tệp được liên kết Vị trí tệp cụ thể được mô tả bằng đường dẫn tệp yêu cầu cấp quyền truy cập vào các thư mục đã truy cập dọc theo đường dẫn, bất kỳ liên kết file nào trong đường dẫn và cuối cùng là ủy quyền cho tệp đích cụ thể các hoạt động được yêu cầu Vì các thành phần này được trích xuất từ đường dẫn tệp tại các điểm khác nhau trong quá trình xử lý mở, nên vị trí móc LSM không quan trọng.

Mặc dù có một số kiểm tra tuỳ ý giúp hướng dẫn vị trí của móc LSM cho open, quá trình mà các móc LSM được đặt phần lớn là đặc biệt Đối với những người không có ủy quyền tùy ý trước đó được thực hiện, người triển khai thực hiện một vị trí thủ công Một số vị trí được phát hiện là sai và một số hoạt động nhạy cảm về bảo mật được phát hiện là thiếu hòa giải, nhưng những vấn đề này đã được giải quyết thông qua phân tích mã nguồn [351, 149].

Một móc LSM được đặt trong mã bằng cách sử dụng khai báo hàm nội tuyến (ví dụ: security_inode_create) được mở rộng tại thời điểm biên dịch thành các móc LSM như được hiển thị trong đoạn mã trên Các hàm nội tuyến cho mỗi móc LSM được sử dụng để cải thiện khả năng đọc của mã.

Triển khai bộ giám sát chuẩn LSM Cuối cùng, các LSM phải được xây dựng để thực hiện các ủy quyền thực tế Các LSM thực tế bao gồm AppArmor [228], Hệ thống phát hiện xâm nhập Linux (LIDS) [183], SELinux [229] và Tính năng POSIX

[307] Mỗi LSM cung cấp một cách tiếp cận khác nhau để kiểm soát truy cập bắt buộc, ngoại trừ tính năng POSIX vốn là một cơ chế tùy ý hiện có trong Linux Các khả năng của POSIX đã được chuyển đổi thành một mô-đun để cho phép phát triển độc lập từ nhân dòng chính và vì một số LSM nhằm thực hiện các điều khiển khả năng theo một cách khác [342]

Mặc dù Gasser và Schell đã xác định rằng các chính sách nhân bảo mật khác nhau yêu cầu các giao diện giám sát tham chiếu khác nhau (tức là các vị trí móc LSM khác nhau) [10] (trong ngữ cảnh của nhân bảo mật, xem Chương 6), LSM sử dụng các vị trí giống nhau cho tất cả các LSM Trong thực tế, việc lựa chọn các vị trí mócLSM là sự kết hợp của các bộ giám sát chuẩn được chuyển đến khung Việc triển khaiLSM không yêu cầu mỗi LSM cung cấp các triển khai cho mọi hook, do đó, phương pháp thống nhất không yêu cầu các nhà phát triển LSM phải làm thêm việc Tuy nhiên, bộ móc LSM phần lớn đã ổn định.

Hình 9 1: Cấu trúc móc LSM

Một ví dụ về loại chính sách được thực hiện bởi LSM là chính sách hạn chế củaAppArmor [228] AppArmor là một hệ thống kiểm soát truy cập (MAC) bắt buộc, nơi mối đe dọa tập trung vào Internet Nếu chúng ta giả định rằng hệ thống được cấu hình đúng, thì Internet là cách duy nhất mà đầu vào độc hại có thể tiếp cận hệ thống Một mối đe dọa là các daemon đối mặt với mạng (ví dụ: inetd) dễ bị nhiễm các đầu vào độc hại (ví dụ: tràn bộ đệm, lỗ hổng chuỗi định dạng, v.v.) AppArmor sử dụng các chính sách hạn chế đối với các mạng trực diện như vậy, theo thường lệ được chạy với đầy đủ đặc quyền (ví dụ: root), để ngăn các daemon bị xâm nhập làm ảnh hưởng đến toàn bộ hệ thống.

BẢO MẬT NÂNG CAO CHO LINUX

BỘ GIÁM SÁT CHUẨN SELINUX

Bộ giám sát chuẩn SELinux bao gồm hai bước xử lý riêng biệt Đầu tiên, trình giám sát tham chiếu SELinux chuyển đổi các giá trị đầu vào từ các móc LSM thành một hoặc nhiều truy vấn ủy quyền Các móc LSM này bao gồm các tham chiếu đến các đối tượng Linux (ví dụ: tham chiếu đối tượng tệp và ổ cắm) và trong một số trường hợp, cờ đối số, nhưng trình giám sát tham chiếu SELinux phải chuyển đổi chúng thành các truy vấn ủy quyền SELinux (xem hình trên) Thứ hai, lõi của bộ giám sát chuẩn SELinux xử lý các truy vấn ủy quyền này đối với hệ thống bảo vệ SELinux (tức là trạng thái bảo vệ, trạng thái ghi nhãn và trạng thái chuyển tiếp) Biểu diễn hệ thống bảo vệ SELinux được tối ưu hóa cao để hỗ trợ hiệu quả các truy vấn ủy quyền chi tiết.

Hãy xem xét ví dụ bên dưới, việc triển khai SELinux đằng sau móc LSM cho phép một lệnh gọi hệ thống mở tệp static int selinux_inode_permission(struct inode *inode, int mask, struct nameidata *nd) { if (!mask) {

/* No permission to check Existence test */ return 0;

} return inode_has_perm(current, inode, file_mask_to_av(inode->i_mode, mask), NULL);

Hình 9 2: Cấu trúc hệ thống SELinux

Nhớ lại rằng khi lệnh gọi hệ thống open được gọi, tệp đích được chỉ định bởi tên đường dẫn UNIX và các hoạt động được yêu cầu được chỉ định bằng cách sử dụng một cờ vectơ bit Quá trình triển khai open của hạt nhân giải quyết tên đường dẫn xuống inode thực tham chiếu đến tệp đích và sau đó nó gọi ra móc LSM để cho phép liệu quá trình yêu cầu có thể thực hiện các hoạt động được yêu cầu trên inode hay không.

Hàm selinux_inode_permission ở trên có ba đối số, inode cho tệp tin, mask cho biết hoạt động của tệp và namedata liên quan đến đường dẫn tệp (không được sử dụng trong ủy quyền này)

Việc triển khai SELinux xác định các đối tượng Linux cụ thể tương ứng với mục tiêu, đối tượng và các hoạt động cho việc truy vấn ủy quyền Đầu tiên, đối tượng của một lệnh gọi hệ thống mở là quá trình gửi lệnh gọi hệ thống Trong Linux, tiến trình đã gọi một lệnh gọi hệ thống được xác định bởi biến toàn cục current Do đó, đây không cần phải là đầu vào từ móc LSM Thứ hai, đối tượng của một phép gọi open là inode Tham chiếu đến inode được bao gồm trong móc LSM Thứ ba, các hoạt động được yêu cầu bởi một lệnh gọi hệ thống mở (ví dụ: đọc, ghi và nối thêm) được xác định từ đầu vào flags được gửi đến hàm selinux_inode_permission thông qua biến mask Namedata không được sử dụng bởi SELinux LSM, nhưng có thể được sử dụng bởi các LSM khác.

Chủ đề (current), đối tượng (inode) và các hoạt động (kết quả của file_mask_to_av) được gửi đến hàm inode_has_perm, hàm này tạo ra truy vấn ủy quyền SELinux thực tế như được hiển thị bên dưới. static int inode_has_perm(struct task_struct *tsk, struct inode *inode, u32 perms, struct avc_audit_data *adp)

{ struct task_security_struct *tsec; struct inode_security_struct *isec; struct avc_audit_data ad; tsec = tsk->security; isec = inode->i_security; if (!adp) { adp = &ad;

AVC_AUDIT_DATA_INIT(&ad, FS); ad.u.fs.inode = inode;

} return avc_has_perm(tsec->sid, isec->sid, isec->sclass, perms, adp);

Thay vì gửi các đối tượng trực tiếp trong một truy vấn ủy quyền, SELinux chỉ định nhãn cho các chủ thể và đối tượng, được gọi là ngữ cảnh trong SELinux Như chúng tôi mô tả trong phần tiếp theo, ngữ cảnh chủ đề xác định một tập hợp các quyền (đối tượng và hoạt động) có sẵn cho các quy trình chạy với ngữ cảnh đó Một ngữ cảnh đối tượng nhóm một tập hợp các đối tượng có cùng yêu cầu bảo mật Như yêu cầu đối với một hệ thống bảo vệ bắt buộc, tập hợp các bối cảnh phải được cố định, vì vậy trạng thái bảo vệ là bất biến Tương tự như vậy, các trạng thái ghi nhãn và chuyển tiếp trong hệ thống SELinux cũng là bất biến.

Trong SELinux, hạt nhân lưu trữ một ngữ cảnh với mỗi quy trình và tài nguyên hệ thống có thể xuất hiện trong một móc LSM Đối với các quy trình, task_struct kiểu dữ liệu của nó bao gồm bảo mật trường mà ngữ cảnh chủ đề của quy trình được lưu trữ. inode_has_perm trích xuất ngữ cảnh chủ đề và đối tượng cho các đối số đầu vào này (tức là tsk và inode trong inode_has_perm) và tạo truy vấn ủy quyền SELinux, được xác định bởi hàm avc_has_perm Hàm này nhận bốn đối số: (1) ngữ cảnh chủ đề; (2) bối cảnh đối tượng; (3) phân loại SELinux cho kiểu dữ liệu của đối tượng; và (4) các hoạt động được yêu cầu trong truy vấn Kho lưu trữ chính sách SELinux thực hiện truy vấn này, xác định xem ngữ cảnh chủ đề có thể thực hiện các hoạt động được yêu cầu trên một đối tượng với ngữ cảnh đối tượng được chỉ định hay không và phân loại SELinux cho kiểu dữ liệu của nó Các phân loại như vậy tương ứng với các kiểu dữ liệu hệ thống, chẳng hạn như tệp và ổ cắm, cũng như các kiểu con cụ thể hơn của chúng.

SELinux định nghĩa các truy vấn ủy quyền cho gần như tất cả các móc LSM. Đối với hầu hết các móc LSM này, một truy vấn ủy quyền duy nhất được tạo, nhưng trong một số trường hợp, nhiều truy vấn ủy quyền được tạo và đánh giá Ví dụ: để gửi một gói, quá trình phải có quyền truy cập để gửi bằng cách sử dụng cổng, giao diện mạng và địa chỉ IP được chỉ định (xem ví dụ về selinux_sock_rcv_skb_compat) Mỗi truy vấn ủy quyền này phải được ủy quyền để hoạt động được phép.

Truy vấn ủy quyền trên trạng thái bảo vệ truy xuất mục nhập chính sách SELinux tương ứng với ngữ cảnh chủ đề, ngữ cảnh đối tượng và kiểu dữ liệu đối tượng Mục nhập chính sách chứa các hoạt động được ủy quyền cho sự kết hợp này và avc_has_perm xác định xem tất cả các hoạt động được yêu cầu có được mục nhập cho phép hay không Nếu vậy, các hoạt động được cho phép và quá trình thực thi SELinux trả về 0 Sau đó, nhân Linux được phép thực hiện phần còn lại của lệnh gọi hệ thống (hoặc ít nhất là cho đến khi móc LSM tiếp theo).

TRẠNG THÁI BẢO VỆ CỦA SELINUX

Bộ giám sát chuẩn SELinux thực thi trạng thái bảo vệ SELinux, trạng thái ghi nhãn và trạng thái chuyển tiếp Đầu tiên, chúng ta thảo luận về trạng thái bảo vệ SELinux Các bối cảnh SELinux được mô tả ở trên đại diện cho trạng thái bảo vệ SELinux Chúng là một mô tả phong phú về chính sách kiểm soát truy cập cho phép xác định các chính sách chi tiết Trong phần này, chúng tôi xác định các khái niệm trong các bối cảnh SELinux và mô tả cách chúng thể hiện các yêu cầu bảo mật đối với các quy trình Linux và tài nguyên hệ thống.

Các bối cảnh về SELinux Hình 9.3 cho thấy các khái niệm để định nghĩa một ngữ cảnh SELinux và các mối quan hệ của chúng user là khái niệm SELinux gần nhất với danh tính người dùng UNIX (UID) Người dùng là danh tính được xác thực của người dùng trong hệ thống Điều này thường tương ứng với danh tính người dùngUNIX trong tên, nhưng không chuyển tải bất kỳ quyền truy cập nào cho người dùng.

Trong SELinux, danh tính người dùng chỉ xác định một tập hợp các vai trò mà người dùng được chính sách SELinux cho phép Khi người dùng xác thực (ví dụ: đăng nhập), người dùng có thể chọn một vai trò từ tập hợp được chính sách SELinux ủy quyền.

SELinux role tương tự như khái niệm về vai trò trong mô hình kiểm soát truy cập dựa trên vai trò (RBAC) [94, 268, 272] ở chỗ nó giới hạn tập hợp các quyền mà người dùng có thể truy cập Tuy nhiên, không giống như RBAC role, vai trò này không được chỉ định quyền trực tiếp Thay vào đó, một vai trò SELinux được liên kết với một tập hợp các nhãn kiểu, như trong mô hình Type Enforcement (TE) [33] và các nhãn type được gán quyền Vai trò cũng tùy chọn xác định phạm vi MLS xử lý trong vai trò có thể giả sử Khi người dùng được xác thực, điều này xác định vai trò của người dùng và tất cả các quy trình mà người dùng chạy phải có nhãn phân loại và MLS range được ủy quyền cho vai trò của người dùng

Hình 9 3: SELinux contexts: người dùng giới hạn tập hợp các vai trò có thể được đảm nhận cho Vai trò 1 hoặc Vai trò 2 (chỉ một vai trò) Các vai trò giới hạn tập hợp các loại chủ đề và phạm vi MLS mà một quy trình có thể giả định (và do đó, quyền có sẵn cho người dùng) Một ngữ cảnh có thể chỉ có một loại chủ đề, nhưng một quy trình có thể chuyển đổi giữa tất cả các loại chủ đề được liên kết với một vai trò

Ví dụ: một người dùng xác thực danh tính trong vai trò người dùng user _r Vai trò này được phép chạy các quy trình người dùng điển hình dưới nhãn loại user_t, nhưng cũng được phép chạy các quy trình khác có nhãn loại mà user_r được cấp quyền Vai trò người dùng user_r cho phép người dùng alice sử dụng chương trình passwd để thay đổi mật khẩu của mình, nhưng vì chương trình này có các quyền khác với chương trình người dùng thông thường (ví dụ: nó có thể sửa đổi / etc / shadow, tệp chứa mật khẩu người dùng đã băm) nên chạy dưới nhãn loại khác, passwd_t Do đó, vai trò người dùng user_r được phép chạy các quy trình dưới nhãn kiểu user_t và passwd_t.

Nhãn loại được gán cho quyền bằng cách sử dụng câu lệnh allow như được hiển thị bên dưới allow : allow user_t passwd_exec_t:file execute allow passwd_t shadow_t :file {read write}

Câu lệnh allow liên kết kiểu chủ đề (ví dụ: user _t) với các quyền được mô tả dưới dạng đối tượng (ví dụ: passwd_exec_t, nhãn của tệp thực thi passwd), kiểu dữ liệu của đối tượng (ví dụ: tệp thực thi passwd là một tệp ), và tập hợp các thao tác trên kiểu đối tượng được ủy quyền bởi câu lệnh allow (ví dụ: thực thi) Do đó, câu lệnh allow đầu tiên cho phép bất kỳ quá trình nào có nhãn kiểu user_t thực thi bất kỳ tệp nào có nhãn kiểu passwd_exec_t Câu lệnh allow thứ hai cho phép bất kỳ tiến trình nào chạy với nhãn loại passwd_t đọc hoặc ghi bất kỳ tệp nào có nhãn loại shadow_t. Điều này giới hạn quyền truy cập vào / etc / shadow đối với những quy trình chạy dưới nhãn loại passwd_t, thường chỉ những quy trình chạy passwd.

Các nhãn MLS của SELinux đại diện cho một chính sách mạng truyền thống bao gồm các mức độ nhạy cảm và các nhóm danh mục Các nhãn MLS được diễn giải theo mô hình Bell LaPadula [23] (xem Chương 5) cho các thao tác đọc, nhưng cách diễn giải thận trọng hơn được sử dụng để cho phép các thao tác ghi Đối với một thao tác đọc, mức độ nhạy cảm của đối tượng phải chiếm ưu thế (tức là lớn hơn) hoặc bằng mức độ nhạy cảm của đối tượng và nhóm danh mục của chủ thể phải bao gồm tất cả(tức là, là một tập hợp lớn hơn của) nhóm danh mục của đối tượng (tức là, tài sản bảo đảm đơn giản) Đối với thao tác ghi, mức độ nhạy cảm của chủ thể phải bằng mức độ nhạy cảm của đối tượng và các nhóm danh mục chủ thể cũng phải bằng mức độ nhạy cảm của đối tượng Điều này hạn chế hơn quy tắc viết MLS thông thường dựa trên thuộc tính -security Thuộc tính -security cho phép ghi lên, khả năng cho các đối tượng ở mức độ nhạy cảm thấp hơn có thể ghi vào các đối tượng ở mức độ nhạy cao hơn -Property giả định rằng các quy trình bí mật thấp hơn không biết bất kỳ điều gì về các tệp bí mật cao (tức là mức độ nhạy cảm của chủ thể bị chi phối bởi đối tượng), chẳng hạn như liệu có tồn tại tệp bí mật cao hơn của một tên cụ thể hay không Tuy nhiên, các quy trình Linux không quá khó đoán, vì vậy một quy trình Linux có thể đoán được tên của một tệp được quy trình bảo mật cao hơn sử dụng, do đó ảnh hưởng đến tính toàn vẹn của hệ thống Do đó, không được phép ghi lên trong SELinux

Bộ giám sát chuẩn SELinux cho phép cả nhãn loại của chủ thể và nhãn MLS đều cho phép thực hiện các thao tác được yêu cầu trên đối tượng yêu cầu dựa trên nhãn loại và nhãn MLS của nó Hai nhãn được ủy quyền độc lập như mô tả ở trên. Đối với nhãn kiểu, quy tắc cho phép phải được xác định cho phép kiểu chủ thể thực hiện các thao tác được yêu cầu trên kiểu đối tượng tương ứng Ngoài ra, các nhãn MLS của chủ thể và đối tượng cũng phải cho phép hoạt động được yêu cầu Cả hai bài kiểm tra ủy quyền phải vượt qua trước khi hoạt động được ủy quyền.

Các chính sách của SELinux Trạng thái bảo vệ SELinux cho phép thể hiện toàn diện, chi tiết các yêu cầu bảo mật của hệ thống Đầu tiên, mỗi kiểu dữ liệu đối tượng riêng biệt và hoạt động trong hệ thống Linux được phân biệt trong trạng thái bảo vệ SELinux Trạng thái bảo vệ SELinux bao gồm tất cả các kiểu dữ liệu tài nguyên hệ thống nhạy cảm với bảo mật, bao gồm nhiều loại tệp khác nhau, nhiều loại ổ cắm khác nhau, bộ nhớ dùng chung, giao tiếp giữa các quá trình, bán kết, v.v Có hơn 20 kiểu dữ liệu đối tượng khác nhau Ngoài ra, SELinux cung cấp một tập hợp các thao tác phong phú cho từng kiểu dữ liệu Ngoài các thao tác đọc, ghi và thực thi truyền thống trên tệp, kiểu dữ liệu tệp tiêu chuẩn trong SELinux có các thao tác tạo, ioctl, fcntl, các thuộc tính mở rộng, v.v Nhờ đó, kiểm soát toàn diện và chi tiết các tài nguyên hệ thống có khả năng

Thứ hai, mỗi quy trình và đối tượng với các yêu cầu bảo mật khác nhau đòi hỏi một bối cảnh bảo mật riêng biệt Nếu hai quy trình không thể truy cập chính xác cùng một nhóm đối tượng với chính xác cùng một nhóm đối tượng, thì hai nhãn loại chủ đề riêng biệt là cần thiết, một nhãn cho mỗi quy trình Sau đó, thích hợpcho phép các câu lệnh cho mỗi có thể được xác định Ví dụ: các loại chủ đề riêng biệt cho user_t và passwd_t phải được định nghĩa vì passwd có thể truy cập / etc / shadow trong khi quy trình người dùng thông thường không thể Hơn nữa, nếu hai đối tượng không thể được truy cập bằng các quy trình giống hệt nhau, thì chúng cũng yêu cầu hai nhãn kiểu đối tượng riêng biệt Một lần nữa, các nhãn loại đối tượng shadow_t và passwd_exec_t là cần thiết vì hai tệp này (/ etc / shadow và tệp thực thi passwd) hơn 1000 nhãn kiểu được xác định trong chính sách tham chiếu SELinux, trạng thái bảo vệ SELinux mặc định và hàng chục nghìn câu lệnh allow là cần thiết để thể hiện tất cả các mối quan hệ khác nhau giữa các chủ thể và đối tượng trong hệ thống Linux.

Trong khi mô hình chính sách SELinux dẫn đến các biểu diễn trạng thái bảo vệ phức tạp, thì độ phức tạp của trạng thái bảo vệ là kết quả của sự phức tạp của hệ thống Linux Linux bao gồm nhiều chương trình khác nhau, hầu hết có các yêu cầu truy cập riêng biệt và các yêu cầu bảo mật riêng biệt, dẫn đến một số lượng lớn các nhãn kiểu Khi đó, một số lượng lớn các nhãn kiểu yêu cầu một số lượng lớn các câu lệnh allow để thể hiện tất cả các mối quan hệ truy cập cần thiết Chính sách tham chiếu SELinux thể hiện những gì chúng tôi đang chống lại khi cố gắng xây dựng các hệ thống Linux an toàn.

TRẠNG THÁI GHI NHÃN SELINUX

Vì trạng thái bảo vệ SELinux được xác định theo nhãn, như là điển hình của chính sách truy cập bắt buộc, trạng thái bảo vệ phải được ánh xạ tới tài nguyên hệ thống thực tế Mức độ khó tin trong phần trước khiến chúng tôi khó tin vì, trong khi chúng tôi đề cập rằng một số tệp nhất định, chẳng hạn như / etc / shadow có một số nhãn nhất định, chẳng hạn như shadow_t, chúng tôi đã không chỉ rõ cách các tệp thu được các nhãn này ngay từ đầu Hơn nữa, các quy trình cũng được gán nhãn, chẳng hạn như quy trình passwd có nhãn passwd_t và ánh xạ nhãn tới các quy trình cũng phải được xác định.

Các thông số kỹ thuật này được cung cấp trong cái mà chúng tôi gọi là trạng thái ghi nhãn của hệ thống bảo vệ bắt buộc trong Định nghĩa 2.4 Trạng thái gắn nhãn là một chính sách bất biến xác định cách các quy trình và tài nguyên hệ thống mới tạo được gắn nhãn SELinux cung cấp bốn cách để xác định nhãn của một đối tượng. Đầu tiên, một đối tượng có thể được gắn nhãn dựa trên vị trí của nó trong hệ thống tệp Giả sử các tệp / etc / passwd và / etc / shadow được cung cấp trong một gói Linux cho chương trình passwd Trong trường hợp này, tệp đã tồn tại ở một số dạng và cần được gắn nhãn khi nó được cài đặt SELinux sử dụng ngữ cảnh tệp để gắn nhãn tệp hiện có hoặc tệp được cung cấp trong gói Đặc tả ngữ cảnh tệp ánh xạ biểu thức đường dẫn tệp tới ngữ cảnh đối tượng Biểu thức đường dẫn tệp là một biểu thức chính quy mô tả một tập hợp các tệp có đường dẫn tệp phù hợp với biểu thức đó. Dưới đây, chúng tôi liệt kê hai đặc tả ngữ cảnh tệp.

/etc/ shadow.* /etc/*.*

system_u:object_r:shadow_t:s0 system_u:object_r:etc_t:s0

Ví dụ, định nghĩa ngữ cảnh tệp thứ hai ở trên xác định ngữ cảnh đối tượng cho các tệp trong thư mục / etc / etc / shadow nhận ngữ cảnh đặc biệt trong khi các tệp khác trong / etc (ví dụ: / etc / passwd) nhận ngữ cảnh mặc định.

Thứ hai, đối với các đối tượng được tạo động, nhãn của chúng được kế thừa từ đối tượng mẹ của chúng Đối với các tệp, điều này được xác định bởi thư mục mẹ. Đối với tất cả các tệp được tạo động trong thư mục / etc, chúng kế thừa nhãn được xác định cho thư mục, etc_t.

Thứ ba, các quy tắc type_transition có thể được chỉ định trong chính sách SELinux ghi đè nhãn đối tượng mặc định Dưới đây, chúng tôi hiển thị quy tắc type_transition gắn nhãn lại tất cả các tệp được tạo bởi các quy trình với loại passwd_t sẽ được gán nhãn etc_t theo mặc định cho nhãn passwd_t. type_transition : type_transition passwd_t etc_t:file shadow_t

Lưu ý rằng ngữ cảnh quy trình tạo phải được ủy quyền để gắn nhãn lại các tệp etc_t này thành tệp passwd_t 4 Nếu chúng tôi sử dụng quy trình passwd để tạo / etc / shadow, trong đó / etc có nhãn etc_t, nó sẽ được gán nhãn shadow_t thay thế dựa trên quy tắc này.

Trạng thái gắn nhãn SELinux thực thi các mục tiêu bảo mật thông qua ngữ cảnh tệp do quản trị viên chỉ định, nhãn mặc định và quy tắc type_transition được ủy quyền Trạng thái gắn nhãn cho phép kiểm soát chính xác việc dán nhãn, nhưng không nhất thiết đảm bảo mục tiêu bảo mật nhất quán (tức là luồng thông tin) Phân tích bên ngoài là cần thiết để xác định xem trạng thái ghi nhãn có đạt được độ bảo mật mong muốn hay không, như chúng ta đã thảo luận trong phần đánh giá SELinux.

TRẠNG THÁI CHUYỂN GIAO SELINUX

Theo mặc định, một quy trình được gắn nhãn với nhãn của quy trình gốc, như được mô tả ở trên, nhưng trạng thái chuyển tiếp SELinux cho phép chuyển đổi nhãn quy trình Nếu một quy trình của trình bao người dùng chạy với nhãn user_t, thì tất cả các quy trình được tạo từ trình bao này cũng được chạy dưới nhãn user_t Mặc dù điều này có ý nghĩa đối với nhiều chương trình, chẳng hạn như trình chỉnh sửa, ứng dụng email và trình duyệt web, một số chương trình mà người dùng chạy cần các quyền khác nhau Ví dụ: chương trình mật khẩu cần quyền truy cập không được phép đối với các chương trình người dùng điển hình, chẳng hạn như quyền truy cập ghi vào / etc / passwd and read-write access to /etc/shadow.

Các quy tắc type_transition của SELinux cũng được sử dụng để thể hiện các chuyển đổi nhãn quy trình như vậy Như hình dưới đây, cú pháp tương tự như trường hợp gán nhãn đối tượng, nhưng ngữ nghĩa hơi khác một chút. type_transition :process type_transition user_t passwd_exec_t:process passwd_t Đối với chuyển đổi nhãn quy trình, quy tắc type_transition chỉ định rằng một quy trình đang chạy trong một nhãn cụ thể (tức là loại chương trình) thực thi một tệp có nhãn cụ thể, sau đó quy trình này được gắn nhãn lại thành loại kết quả.

Như trường hợp ghi nhãn đối tượng, các chuyển đổi nhãn quy trình khi thực thi phải được ủy quyền Điều này yêu cầu ba quyền SELinux: (1) quy trình phải có quyền truy cập thực thi vào loại tệp thực thi; (2) tiến trình phải được phép chuyển đổi khi thực thi tệp đó; và (3) quy trình phải được cấp phép để chuyển nhãn của nó sang loại_kết quả Trong trường hợp trên, trình bao người dùng tự phân tách và thực thi tệp mật khẩu Tại thời điểm thực thi, quy tắc type_transition được gọi Trình giám sát tham chiếu SELinux truy xuất các quy tắc như vậy và cho phép các điều kiện cần thiết để gọi quy tắc Nếu quá trình chuyển đổi được cho phép, thì quá trình này sẽ được chạy bằng nhãn passwd_t và nó có thể truy cập các tệp / etc / passwd và / etc / shadow nếu cần.

Lưu ý rằng chuyển đổi nhãn quy trình SELinux chỉ được phép thực hiện quy trình 5 Khi một quy trình được thực thi, hình ảnh quy trình cũ được thay thế bằng hình ảnh mới được xác định bởi tệp đang được thực thi, do đó, ngữ cảnh quy trình có thể được chỉ định lại dựa trên hình ảnh này Lưu ý rằng có thể có một số chuyển tiếp từ quy trình cũ, chẳng hạn như tập hợp các bộ mô tả tệp được mở khi thực thi và các biến môi trường quy trình, nhưng các quy tắc chuyển tiếp SELinux có thể giới hạn các ngữ cảnh mà chuyển tiếp được phép Ví dụ: nếu một chương trình phụ thuộc vào việc được chạy với một tập hợp các biến môi trường có tính toàn vẹn cao, thì chỉ cho phép chuyển đổi từ các ngữ cảnh có tính toàn vẹn cao Trong trường hợp mật mã, nó được chạy từ các quy trình người dùng không đáng tin cậy, vì vậy tệp thực thi mật mã phải được tin cậy để bảo vệ chính nó khỏi bất kỳ đầu vào toàn vẹn thấp nào được cung cấp tại thời điểm thực thi.

Chuyển đổi quy trình SELinux an toàn hơn chuyển đổi quy trình UNIX truyền thống thông qua setuid theo một số cách Đầu tiên, quá trình chuyển đổi setuid hầu như luôn dẫn đến một quá trình chạy với đầy đủ các đặc quyền của hệ thống (tức là quá trình gốc setuid) Trong SELinux, quá trình chuyển đổi sang một nhãn cụ thể với các quyền hạn chế được xác định cho mục đích của nó Thứ hai, UNIX cho phép bất kỳ quá trình nào thực hiện một chương trình setuid Kết quả là, tất cả các chương trình setuid đều dễ bị đầu vào độc hại từ các lệnh gọi không đáng tin cậy Trong SELinux, các ngữ cảnh mà theo đó một tiến trình có thể được gọi có thể bị giới hạn.

Ví dụ, các quy tắc SELinux có thể được viết để đảm bảo rằng chỉ những ngữ cảnh đáng tin cậy mới có thể thực thi một chương trình và có được tất cả các quyền của nó.

Chuyển đổi SELinux có thể so sánh với chuyển tiếp Đa phương, xem Chương

3 Trong Đa phương, dấu ngoặc tròn giới hạn quy trình nào có thể gây ra chuyển đổi nhãn quy trình bằng cách thực thi mã đáng tin cậy hơn Tuy nhiên, các điều khiển SELinux được chi tiết hơn, vì chúng có thể được xác định ở cấp độ của một chương trình riêng lẻ, chứ không phải là một vòng bảo vệ Tuy nhiên, Multics định nghĩa một khái niệm chính thức để đảm bảo rằng miền bảo vệ được bảo vệ khỏi các đầu vào độc hại, những người gác cổng SELinux không có khái niệm như vậy, mà phụ thuộc vào nhà phát triển chương trình để đảm bảo bảo vệ.

Cuối cùng, SELinux hiện cung cấp các cơ chế cho phép quá trình tự gắn nhãn lại hoặc tài nguyên hệ thống bằng cách sử dụng lệnh setcon và chsid tương ứng Đối với tài nguyên hệ thống, quy trình passwd có thể gọi rõ ràng chsid để gắn nhãn lại / etc / shadow vào nhãn shadow_t Bất kỳ quá trình nào được SELinux biết đều có thể yêu cầu gắn nhãn lại tệp, nhưng trình giám sát tham chiếu SELinux cho phép tất cả các chuyển đổi này Nghĩa là, một passwd_t cũng phải được ủy quyền để gắn nhãn lại các tệp passwd_t thành shadow_t.

QUẢN TRỊ SELINUX

Vì SELinux sử dụng chính sách kiểm soát truy cập bắt buộc (MAC), nên chỉ quản trị viên hệ thống mới có thể sửa đổi trạng thái của hệ thống bảo vệ Kết quả là, các trạng thái này nói chung là tĩnh SELinux cung cấp hai cơ chế để cập nhật hệ thống bảo vệ của nó: (1) tải chính sách nguyên khối và (2) tải chính sách mô- đun Trong cả hai trường hợp, việc cấu hình các chính sách SELinux là nhiệm vụ của các chuyên gia, vì vậy chỉ một số lượng nhỏ các chính sách được phát triển.

Chính sách nguyên khối Các trạng thái của hệ thống bảo vệ SELinux truyền thống được định nghĩa là một biểu diễn nhị phân, toàn diện, duy nhất được tạo ra từ các câu lệnh chính sách (ví dụ: allow, type_transition, v.v.) được mô tả ở trên Checkpolicy của trình biên dịch chính sách SELinux xây dựng các tệp nhị phân chính sách như vậy Đối với chính sách nguyên khối, hàng chục nghìn câu lệnh chính sách SELinux được biên dịch thành một tệp nhị phân có kích thước trên 3 MB.

Chương trình đáng tin cậy load_policy cho phép quản trị viên tải một trạng thái bảo vệ mới thay thế hoàn toàn trạng thái bảo vệ cũ load_policy sử dụng hệ thống tệp

Sysfs của Linux để tải tệp nhị phân vào nhân Linux nơi trình giám sát tham chiếu SELinux trong nhân có thể sử dụng nó Tất cả các truy vấn ủy quyền được kiểm tra dựa trên chính sách nhị phân.

Chính sách mô-đun, Vì chính sách SELinux thực sự được xác định cho mỗi chương trình Linux và bản thân các chương trình Linux có thể được cài đặt dần dần thông qua các gói, cơ chế quản trị chính sách SELinux cũng đã được mở rộng để hỗ trợ sửa đổi gia tăng Các mô-đun chính sách của SELinux xác định các đóng góp trạng thái bảo vệ theo chương trình cụ thể Một nhị phân chính sách SELinux toàn diện được xây dựng từ các mô-đun riêng lẻ này Mô- đun chính sách bao gồm bốn phần: (1) các nhãn loại riêng của nó và cho phép các quy tắc cho các loại này; (2) đặc tả ngữ cảnh tệp của nó xác định cách các tệp của nó được gắn nhãn; (3) các giao diện của nó cho phép các mô- đun khác truy cập các nhãn loại của nó; và (4) mô-đun này sử dụng các giao diện của mô-đun khác. Định nghĩa nhãn kiểu, quy tắc cho phép và ngữ cảnh tệp không khác gì so với chính sách nguyên khối, được mô tả trong các ví dụ ở trên, nhưng mô-đun chính sách bổ sung thêm khái niệm về giao diện mô-đun [324] Giao diện mô-đun, giống như giao diện phương thức công khai trong chương trình hướng đối tượng, cung cấp điểm vào cho các mô-đun khác để truy cập nhãn loại của mô-đun Ví dụ: một định nghĩa giao diện chỉ định một tập hợp các quy tắc cho phép được phép cho mô-đun gọi giao diện Ví dụ, mô-đun chính sách hạt nhân định nghĩa một giao diện kernel_read_system_state (arg) trong đó nhãn kiểu được gửi dưới dạng đối số arg được gán để cho phép các quy tắc cho phép truy cập đọc vào trạng thái hệ thống Mô- đun chính sách chỉ định cả giao diện của chính nó và tập hợp các giao diện mà nó sử dụng Mô-đun chức năng được sử dụng để tải mô-đun mới vào tệp nhị phân chính sách SELinux.

Phát triển chính sách Ban đầu, hai loại chính sách của SELinux đã được phát triển:

(1) chính sách nghiêm ngặt và (2) chính sách có mục tiêu Chính sách nghiêm ngặt nhằm thực thi đặc quyền ít nhất đối với tất cả các chương trình Linux, do đó tối đa hóa khả năng bảo vệ có thể trong khi vẫn cho phép chức năng hợp lý Chính sách nghiêm ngặt đưa ra hai thách thức đối với việc triển khai Đầu tiên, nó có thể hạn chế hơn những gì các chương trình Linux mong đợi, dẫn đến việc một số chương trình không chạy đúng cách Thứ hai, chính sách nghiêm ngặt không thực thi bất kỳ mục tiêu chính thức nào về bí mật hoặc toàn vẹn, vì vậy chính sách vẫn có thể cho phép các lỗ hổng nghiêm trọng.

Nguyên tắc chính sách nhắm mục tiêu đã được giới thiệu bởi AppArmor LSM

[228] và nó xác định các chính sách đặc quyền ít nhất cho các daemon đối mặt với mạng để bảo vệ hệ thống khỏi đầu vào mạng không đáng tin cậy Các chương trình khác chạy không hạn chế Điều này giới hạn nhiệm vụ định cấu hình các chính sách hạn chế đối với các daemon đối diện với mạng, điều này giúp đơn giản hóa việc biểu đạt chính sách và gỡ lỗi Tuy nhiên, chính sách được nhắm mục tiêu không bảo vệ hệ thống khỏi các yếu tố đầu vào có tính toàn vẹn thấp khác (ví dụ: email độc hại, mã đã tải xuống, phần mềm độc hại được cài đặt dưới một nhãn khác) Do đó, chính sách được nhắm mục tiêu phù hợp hơn với các hệ thống máy chủ có phần mềm được quản lý cẩn thận nhưng có thể dễ bị ảnh hưởng bởi các yêu cầu mạng độc hại Trên thực tế, các bản phân phối SELinux (ví dụ: RedHat) được phân phối với chính sách SELinux được nhắm mục tiêu.

Gần đây, chính sách SELinux thứ ba, chính sách tham chiếu, đã được xác định

[309] Chính sách tham chiếu cho phép quản trị viên xây dựng chính sách được nhắm mục tiêu hoặc chính sách nghiêm ngặt từ một tập hợp các tệp chính sách Tệp cấu hình cho phép quản trị viên mô tả các thông số kỹ thuật của họ để xây dựng chính sách Chính sách tham chiếu cũng bao gồm hỗ trợ MLS theo mặc định.

CÁC CHƯƠNG TRÌNH TIN CẬY CỦA SELINUX

Ngoài các hoạt động của quản trị viên ở trên để tải chính sách (tức là load_policy và semodule), có nhiều chương trình cấp người dùng khác được tin cậy để chỉ định và / hoặc thực thi các yêu cầu bảo mật của SELinux để hệ thống SELinux được an toàn Các chương trình này bao gồm các chương trình xác thực (ví dụ: sshd) cần thiết để thiết lập ngữ cảnh chủ thể của người dùng đã được xác thực, các dịch vụ hệ thống cần thiết để khởi động hệ thống (ví dụ: init) và các chương trình máy chủ phụ thuộc vào để thực thi chính sách SELinux về hoạt động của họ.

Các chương trình xác thực đã được sửa đổi để hiểu các ngữ cảnh SELinux Khi người dùng xác thực, các chương trình này sẽ thông báo cho trình giám sát tham chiếu SELinux, vì vậy nó có thể chỉ định ngữ cảnh chủ đề thích hợp cho các quy trình của người dùng đó.

Các dịch vụ bootstrap hệ thống chủ yếu được tin cậy vì chúng có các quyền rộng có thể cho phép chúng xâm phạm tính toàn vẹn của chính sách và / hoặc giám sát tham chiếu SELinux Các dịch vụ này chạy với đặc quyền gần như đầy đủ và được tin cậy là không sửa đổi hoặc phá vỡ chính sách Ví dụ: các quy trình như vậy sử dụng ngã ba / hành pháp UNIX truyền thống khi chúng khởi động các dịch vụ hệ thống (ví dụ: vsftpd), để các quy trình này có được bộ quyền truy cập thích hợp thông qua ghi nhãn quy trình(tức là thông qua quy tắc type_transition), như được mô tả ở trên.

SELinux cũng bao gồm một số chương trình máy chủ đã được sửa đổi để thực thi các chính sách của SELinux Một máy chủ mẫu là máy chủ SELinux X [325] Máy chủ X cung cấp các cơ chế có thể cho phép một máy khách lấy thông tin bí mật hoặc xâm phạm tính toàn vẹn của máy khách khác Điều này từ lâu đã được biết đến như một vấn đề [85], và một số triển khai thực thi quyền truy cập cho các hệ thống cửa sổ đã được phát triển trong nhiều năm [90, 86, 42, 199, 289, 95] Cộng đồng SELinux đã xây dựng một giao diện giám sát tham chiếu cho máy chủ X và xác định một máy chủ chính sách cấp người dùng có thể trả lời các truy vấn ủy quyền [43, 308] Thiết kế máy chủ chính sách nói chung là nó có thể hỗ trợ các yêu cầu ủy quyền từ nhiều quy trình cấp người dùng, tương tự như các trình quản lý đối tượng Flask (xem Chương

7) Mục đích là chính sách cấp người dùng có thể được xác minh để đảm bảo rằng các máy chủ đáng tin cậy đó thực thi chính sách tuân thủ chính sách hệ thống SELinux.

Chính sách MLS của SELinux chứa hơn 30 loại chủ đề được hệ thống tin cậy. Trong nhiều trường hợp, các loại chủ đề được liên kết 1-1 với các chương trình, nhưng một số loại chủ đề, chẳng hạn như init, có nhiều tập lệnh được chạy dưới một loại đáng tin cậy duy nhất Số lượng mã đáng tin cậy càng lớn, càng khó xác minh khả năng chống giả mạo và xác minh tính đúng đắn.

Chúng tôi lưu ý ở đây rằng có một số chương trình mà SELinux không tin tưởng Ví dụ: SELinux không tin tưởng NFS [267] để trả về tệp một cách an toàn Do đó, SELinux liên kết nhãn loại nfs_t cho tất cả các tệp này, bất kể nhãn của chúng trên máy chủ NFS Lý do cho điều này là máy chủ NFS phân phối tệp cho các máy khách của nó một cách rõ ràng, vì vậy kẻ tấn công có thể trả lời bằng tệp sai khi có yêu cầuNFS Các hệ thống tệp có giao tiếp được bảo vệ toàn vẹn, chẳng hạn như Hệ thống tệp Andrew được kerberized [225, 234], có thể được tin cậy để cung cấp các tệp được gắn nhãn Nhiều hệ thống tệp phân tán cung cấp quyền truy cập an toàn vào tệp đã được thiết kế [28, 2, 197, 104, 255, 314] Quy định chi tiết về chủ đề này nằm ngoài phạm vi của cuốn sách này.

ĐÁNH GIÁ BẢO MẬT CỦA SELINUX

Bây giờ chúng tôi đánh giá liệu SELinux có đáp ứng các yêu cầu hệ điều hành an toàn của Chương 2 SELinux cung cấp một khuôn khổ mà trong đó các yêu cầu này có thể được đáp ứng (tức là nó “an toàn” như Multics) hay không, nhưng sự phức tạp của hệ thống dựa trên UNIX gây khó khăn đảm bảo hoàn toàn rằng các yêu cầu này đã được đáp ứng Hơn nữa, các yêu cầu thực tế của hệ thống UNIX (tức là chức năng được yêu cầu) giới hạn khả năng của chúng tôi trong việc cấu hình hệ thống đáp ứng các yêu cầu này Do đó, SELinux cung cấp các cải tiến bảo mật đáng kể so với các hệ thống UNIX truyền thống, (xem Chương 4), nhưng rất khó để định lượng những cải tiến này trong phạm vi yêu cầu của một hệ điều hành an toàn.

1 Hòa giải hoàn chỉnh: Làm thế nào để giao diện bộ giám sát chuẩn đảm bảo rằng tất cả các hoạt động nhạy cảm với bảo mật được dàn xếp mà không tạo ra các vấn đề bảo mật, chẳng hạn như TOCTTOU?

Giao diện giám sát tham chiếu của khung Mô- đun bảo mật Linux được thiết kế để cho phép truy cập vào các đối tượng thực tế được nhân sử dụng trong các hoạt động nhạy cảm với bảo mật để ngăn chặn các lỗ hổng, chẳng hạn như TOCTTOU.

2 Hòa giải hoàn chỉnh: Giao diện bộ giám sát chuẩn có dàn xếp các hoạt động nhạy cảm về bảo mật trên tất cả các tài nguyên hệ thống không?

Khung Mô-đun bảo mật Linux dàn xếp các hoạt động được xác định bởi cộng đồng LSM để dẫn đến các hoạt động nhạy cảm với bảo mật Dàn xếp được cung cấp thực sự là sự kết hợp của tất cả nguyên mẫu bộ giám sát chuẩn Linux được xây dựng.

3 Hòa giải hoàn chỉnh: Làm cách nào để chúng tôi xác minh rằng giao diện bộ giám sát chuẩn cung cấp hòa giải hoàn chỉnh?

Vì giao diện giám sát tham chiếu của khung LSM được thiết kế theo cách thức không chính thức, nên việc xác minh rằng nó cung cấp dàn xếp hoàn chỉnh là cần thiết Các công cụ phân tích mã nguồn được phát triển để xác minh rằng cấu trúc dữ liệu hạt nhân nhạy cảm với bảo mật đã được dàn xếp [351] một cách nhất quán [149] và các lỗi trong giao diện bộ giám sát chuẩn LSM đã được tìm thấy và sửa Tuy nhiên, các công cụ này chỉ mang tính ước lượng của các yêu cầu dàn xếp hoàn chỉnh và chúng không được áp dụng thường xuyên Tuy nhiên, không có lỗi nào trong vị trí giao diện bộ giám sát chuẩn được tìm thấy kể từ khi được giới thiệu trong Linux 2.6.

4 Chống giả mạo: Hệ thống bảo vệ bộ giám sát chuẩn, bao gồm cả hệ thống bảo vệ, khỏi bị sửa đổi như thế nào?

Các bộ giám sát chuẩn LSM, chẳng hạn như SELinux, được chạy trong vòng bảo vệ của trình giám sát, vì vậy chúng được bảo vệ như hạt nhân Mặc dù khung công tác LSM là một giao diện mô-đun, các LSM được biên dịch vào hạt nhân, vì vậy chúng có thể hoạt động tại thời điểm khởi động.

Nhân Linux có thể được truy cập bằng lệnh gọi hệ thống, hệ thống tệp đặc biệt và tệp thiết bị, vì vậy việc truy cập vào các cơ chế này phải đảm bảo chống giả mạo Trong khi quá trình xử lý cuộc gọi hệ thống Linux không cung cấp tính năng lọc đầu vào ở cấp độ cổng Multics, công việc đã được thực hiện để xác minh việc xử lý đầu vào hạt thống Linux cung cấp nhiều hoạt động khác cho phép truy cập vào bộ nhớ nhân Ví dụ, các hệ thống tệp đặc biệt, chẳng hạn như hệ thống tệp / proc và hệ thống tệp sysfs, và các tệp thiết bị cho phép truy cập vào bộ nhớ nhân thông qua các tệp Trạng thái bảo vệ SELinux được cấu hình để giới hạn quyền truy cập vào các quy trình đáng tin cậy (tức là những quy trình có nhãn loại chủ đề đáng tin cậy).

5 Chống giả mạo: Hệ thống bảo vệ của hệ thống có bảo vệ các chương trình cơ sở máy tính đáng tin cậy không?

Như đã mô tả ở trên, tính năng chống giả mạo của hệ thống SELinux cũng yêu cầu các chương trình cấp người dùng đáng tin cậy của nó phải được chống giả mạo Đánh giá về chính sách SELinux cho thấy rằng có thể xác định được một tập hợp các quy trình đáng tin cậy xác định cơ sở tính toán đáng tin cậy, được bảo vệ chống giả mạo

[150] Tuy nhiên, một số quy trình đáng tin cậy này phải được tin cậy để tự bảo vệ khỏi một số đầu vào có tính toàn vẹn thấp, do đó, việc đáp ứng tính toàn vẹn của luồng thông tin cổ điển khi không nhận được đầu vào có tính toàn vẹn thấp (ví dụ: bảo vệ toàn vẹn Biba [27]) có vẻ không thực tế Một số dịch vụ SELinux đáng tin cậy (ví dụ: sshd và vsftpd) đã được chứng minh là thực thi một phiên bản yếu hơn của tính toàn vẹn ClarkWilson [54, 285].

6 Có thể kiểm chứng được: Cơ sở nào cho tính đúng đắn của cơ sở tính toán đáng tin cậy của hệ thống?

Như một điển hình, xác minh tính đúng đắn của việc thực thi an ninh là nhiệm vụ khó đạt được nhất Xác minh tính đúng đắn của việc triển khai nhân Linux và các chương trình đáng tin cậy là một nhiệm vụ rất phức tạp Đối với cơ sở mã lớn này, hầu hết được viết bằng các ngôn ngữ an toàn không kiểu loại, bởi nhiều nhà phát triển, việc xác minh không thể hoàn thành trong thực tế Linux đã được đảm bảo ở mức đánh giá Tiêu chí Chung EAL4 (xem Chương 12), yêu cầu tài liệu về thiết kế mức thấp của hạt nhân Chuyển đổi thiết kế cấp thấp này thành một mô hình trong đó các thuộc tính bảo mật có thể được xác minh sẽ là một nhiệm vụ khó khăn và có thể không thực tế để xác minh cách mã nguồn triển khai thiết kế một cách chính xác.

7 Có thể kiểm chứng được: Hệ thống bảo vệ có thực thi các mục tiêu bảo mật của hệ thống không?

Các chính sách SELinux xác định một đặc tả chính xác, bắt buộc của các hoạt động được phép trong hệ thống Do đó, có thể xây dựng một biểu diễn luồng thông tin từ các chính sách SELinux [150] (đã đề cập ở trên), thậm chí một biểu diễn bao gồm cả trạng thái chuyển tiếp Ngoài ra, chính sách MLS đảm bảo tính bí mật của luồng thông tin đáp ứng các thuộc tính bảo mật và đơn giản Tuy nhiên, phân tích tính toàn vẹn và chính sách MLS tiết lộ một số lượng đáng kể các loại chủ đề đáng tin cậy (trên

30 đối với tính toàn vẹn và trên 30 đối với MLS, và chỉ một số trùng lặp) Do đó, phương pháp SELinux cho phép hệ thống “an toàn”, nhưng các nhà phát triển hệ thống sẽ cần quản lý việc sử dụng mã đáng tin cậy một cách cẩn thận để đảm bảo thực sự đáp ứng được các mục tiêu bảo mật đã xác minh.

TỔNG KẾT

Hệ thống LSM / SELinux thực hiện một bộ giám sát chuẩn trong hệ điều hành Linux. Cộng đồng LSM nổi lên từ nhiều nỗ lực nguyên mẫu để thêm một bộ giám sát chuẩn vào Linux và phát triển một giao diện bộ giám sát chuẩn được cộng đồng bảo mật (phần lớn) và cộng đồng Linux chính thống chấp nhận SELinux và AppArmor LSM đã được các nhà phân phối Linux lớn áp dụng và được nhiều nhà phân phối khác hỗ trợ Mặc dù khung LSM mới chỉ được thử nghiệm bán chính thức, nhưng nhìn chung nó đã là một sự bổ sung thành công cho hạt nhân Tuy nhiên, sự kết hợp giữa hạt nhân Linux và khung LSM quá phức tạp để có một xác minh chính thức hoàn chỉnh được yêu cầu để chứng minh dàn xếp hoàn chỉnh và chống giả mạo.

Thách thức là làm thế nào để sử dụng giao diện bộ giám sát chuẩn LSM để thực thi các mục tiêu bảo mật Chúng tôi đã kiểm tra hệ thống SELinux cung cấp một bộ dịch vụ toàn diện để thực hiện các chính sách bảo mật và một hệ thống bảo vệ chi tiết và linh hoạt để kiểm soát chính xác tất cả các quy trình Các phương pháp tiếp cận SELinux cho thấy sự phức tạp của hệ thống UNIX và khó khăn trong việc thực thi bảo mật toàn diện Thách thức nổi bật là định nghĩa và xác minh các mục tiêu bảo mật mong muốn trong các chính sách cấp thấp này AppArmor LSM sử dụng chính sách được nhắm mục tiêu để bảo vệ hệ thống khỏi các tội phạm mạng, nhưng bằng chứng về việc thực thi mục tiêu bảo mật cũng sẽ phải xác minh các yêu cầu, chẳng hạn như luồng thông tin.