9.2 BẢO MẬT NÂNG CAO CHO LINUX
9.2.7 ĐÁ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 u cầu hệ điều hành an toàn của Chương 2. SELinux cung cấp một khn khổ mà trong đó các yêu cầu này có thể được đáp ứng (tức là nó “an tồ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 hồ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 hồ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 hồ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 hồ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 hồ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 u cầu dàn xếp hồ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 tố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 tồn vẹn thấp, do đó, việc đáp ứng tính tồ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 tồn vẹn thấp (ví dụ: bảo vệ tồ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 tồ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 tố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 tồn khơng kiểu loại, bởi nhiều nhà phát triển, việc xác minh khơng thể hồ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. Ngồ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 tồ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 tồ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.