(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

HỌC VIỆN KỸ THUẬT MẬT MÃ KHOA AN TỒN THƠNG TIN BÁO CÁO BÀI TẬP LỚN AN TOÀN HỆ ĐIỀU HÀNH Đề tài: AN TỒN HỆ ĐIỀU HÀNH LINUX Nhóm sinh viên thực hiện: CAO QUANG TRƯỜNG VÕ VĂN THÔNG NGUYỄN THỊ THUÝ KIỀU LÊ TRÙNG DƯƠNG NGUYỄN HÀ THIÊN PHONG Lớp: AT14N01 Giáo viên hướng dẫn: ThS HÀ NGỌC MINH TP HỒ CHÍ MINH, THÁNG 12 NĂM 2020 MỤC LỤC MỤC LỤC DANH MỤC TỪ VIẾT TẮT .2 DANH MỤC CÁC HÌNH LỜI MỞ ĐẦU .4 9.1 LINUX SECURITY MODULES 9.1.1 LỊCH SỬ LSM 9.1.2 TRIỂN KHAI LSM 9.2 BẢO MẬT NÂNG CAO CHO LINUX 10 9.2.1 BỘ GIÁM SÁT CHUẨN SELINUX 11 9.2.2 TRẠNG THÁI BẢO VỆ CỦA SELINUX 14 9.2.3 TRẠNG THÁI GHI NHÃN SELINUX 18 9.2.4 TRẠNG THÁI CHUYỂN GIAO SELINUX 19 9.2.5 QUẢN TRỊ SELINUX 21 9.2.6 CÁC CHƯƠNG TRÌNH TIN CẬY CỦA SELINUX 23 9.2.7 ĐÁNH GIÁ BẢO MẬT CỦA SELINUX 24 9.3 TỔNG KẾT 27 TÀI LIỆU THAM KHẢO .28 DANH MỤC TỪ VIẾT TẮT SELinux Security-enhanced Linux Tên mô-đun bảo mật CIPSO Common Internet Protocol Security Options Giao thức bảo mật mạng tuỳ chọn phổ biến MAC Mandatory Access Control Điều khiển truy cập bắt UID User Identity buộc Định danh người dùng RBAC Role-based Access Control Điều khiển truy cập sở vai trò TE Type Enforcement Một chế kiểm soát truy cập Linux TOCTTOU Time-of-check to Time-of-use Tên loại lỗi phần mềm LSM Các mô-đun bảo mật Linux Linux Security Modules DANH MỤC CÁC HÌNH Hình 1: Cấu trúc móc LSM Hình 2: Cấu trúc hệ thống SELinux .10 Hình 3: SELinux contexts: .13 LỜI MỞ ĐẦU Ngày nay, nhu cầu trao đổi liệu qua mạng máy tính trở nên vô quan trọng hoạt động xã hội, song song với phát triển bùng nổ mạng máy tính nói chung mạng Internet nói riêng nguy phải đối mặt với hàng loạt đe dọa tiềm tàng virus, sâu máy tính, kiểu công, xâm nhập, vv…là lớn Vấn đề bảo đảm an ninh, an tồn cho thơng tin mạng ngày mối quan tâm hàng đầu công ty, tổ chức, nhà cung cấp dịch vụ Việc bảo vệ an toàn liệu vấn đề cấp thiết, việc lựa chọn hệ điều hành phù hợp, có khả bảo mật tốt, độ tin cậy cao quan trọng Hệ điều hành Linux đời mang theo nhiều đặc tính an tồn bao hàm chế bảo mật, với tính chất mã nguồn mở đánh giá hệ điều hành bảo mật tốt Hơn nữa, Linux server thách thức lớn tình trạng xâm nhập bất hợp pháp Mục tiêu đề tài nghiên cứu tìm hiểu chế bảo mật hệ điều hành Linux, qua thấy tầm quan trọng chế thực vấn đề bảo mật Nghiên cứu xây dựng hệ điều hành an toàn Linux Hệ điều hành Linux hoàn thiện hoàn chỉnh giao diện POSIX thực Linus Torvalds Linux trở nên phổ biến năm 1990, dẫn đến bước tiến Linux, giải pháp thay khả thi cho Windows, đặc biệt cho hệ thống máy chủ (ví dụ: máy chủ web) Khi Linux chấp nhận, nhiều nỗ lực bắt đầu giải vấn đề bảo mật hệ thống UNIX truyền thống (xem Chương 4) Trong chương này, mô tả lại kết việc thực thi kiểm soát truy cập bắt buộc, Linux Security Modules (LSM) framework Khung LSM xác định giao diện giám sát chuẩn cho Linux mà sau có nhiều triển khai giám sát chuẩn khác Chúng kiểm tra giám sát chuẩn LSM, Tăng cường bảo mật Linux (SELinux) đánh giá cách sử dụng khung LSM để triển khai giám sát chuẩn đảm bảo Chương 9.1 LINUX SECURITY MODULES Khung Linux Security Modules (LSM) hệ thống giám sát tham chiếu cho nhân Linux [342] Khung LSM bao gồm hai phần, giao diện giám sát chuẩn tích hợp vào hạt nhân Linux dịng (kể từ phiên 2.6) mô-đun giám sát tham chiếu, gọi LSM, triển khai chức giám sát tham chiếu (tức môđun ủy quyền kho lưu trữ sách, xem lại Chương định nghĩa khái niệm giám sát chuẩn) đằng sau giao diện Một số mơ- đun độc lập phát triển cho khung LSM [228, 183, 127, 229] để triển khai hình thức khác chức giám sát chuẩn (ví dụ: mơ-đun sách khác nhau) Chúng kiểm tra giám sát chuẩn LSM phần LSM nó, Linux tăng cường bảo mật (SELinux) [229] phần Có LSM khác tranh luận cách tiếp cận LSM phù hợp hiệu quả, SELinux chắn phần mềm toàn diện số LSM 9.1.1 LỊCH SỬ LSM Vào cuối năm 1990, hệ điều hành Linux có hỗ trợ cần thiết để biến trở thành thứ thay thị trường hệ thống UNIX Mặc dù có nhiều biến thể UNIX, chẳng hạn AIX HP / UNIX, chí hệ thống mã nguồn mở khác, chẳng hạn biến thể BSD, Linux trở thành nhà lãnh đạo chia sẻ tư hệ thống UNIX Các nhà cung cấp máy chủ lớn, chẳng hạn IBM HP, hỗ trợ đằng sau Linux, nhanh chóng trở thành đối thủ cạnh tranh Microsoft Windows Ngoài ra, vào cuối năm 1990, số dự án xuất nhằm trang bị thêm tính bảo mật khác vào nhân Linux Vì Linux mã nguồn mở nên sửa đổi để đáp ứng yêu cầu họ(miễn họ phát hành mã nguồn trở lại cộng đồng, theo yêu cầu Giấy phép Công cộng GNU [112]) Một loạt hệ thống nguyên mẫu xuất hiện, bao gồm Argus PitBull [13], LIDS [183], AppArmor (ban đầu gọi 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 HP dành cho Linux [ 80], trang bị thêm hệ thống Flask / DTOS / DTMach trước (xem Chương 7), gọi SELinux Tất hệ thống Linux sửa đổi khác theo cách bản, tất nhằm mục đích cung cấp chức bảo mật AppArmor PitBull bán dạng sản phẩm thương mại Năm 2001, nỗ lực phát triển cho việc đưa giám sát chuẩn vào nhân Linux Các vấn đề worm , vi rút công từ chối dịch vụ đạt đến mức đáng lo, chủ yếu tảng Windows Tại hội nghị thượng đỉnh nhân Linux năm đó, SELinux ngun mẫu trình bày, cộng đồng Linux bao gồm Linus Torvalds nói riêng, dường chấp nhận ý kiến giám sát chuẩn cần thiết Tuy nhiên, Linus phải đối mặt với hai thách thức Đầu tiên, ông chun gia bảo mật, ơng dễ dàng định phương pháp tiếp cận cảm thấy khơng thích hợp để ông đưa định Thứ hai, thân cộng đồng bảo mật đồng ý phương pháp "tốt nhất", Linus phụ thuộc vào cộng đồng bảo mật để định hướng cho cách tiếp cận Kết Linus đồng ý với thiết kế dựa mơ- đun nhân giao diện hỗ trợ tất mơ-đun cần thiết Cách tiếp cận trở thành khung LSM Một cộng đồng hình thành xung quanh ý tưởng xây dựng giao diện giám sát chuẩn cho Linux (mặc dù tất nhà nghiên cứu nguyên mẫu bảo mật Linux đồng ý [239, 297] 1), cộng đồng thiết kế triển khai khung LSM Nhiệm vụ thực Giao diện giám sát chuẩn LSM Thiết kế giao diện giám sát chuẩn khung LSM với mục tiêu sau [342]: Giao diện giám sát chuẩn phải thực thống nhất, cho “sử dụng mô-đun bảo mật khác vấn đề tải mơ-đun hạt nhân khác ” • Các giao diện giám sát chuẩn phải “đơn giản mặt khái niệm, xâm lấn tối thiểu hiệu quả” • • Phải hỗ trợ chế khả POSIX.1e “mô-đun bảo mật tùy chọn” Hai yêu cầu thúc đẩy việc thu thập kết hợp truy vấn ủy quyền từtất bảo mật Linux trước đó, tất mơ-đun hỗ trợ, hạn chế số lượng truy vấn ủy quyền nhiều để ngăn chặn ủy quyền thừa, làm tăng thêm độ phức tạp tác động đến hiệu suất Mặc dù giao diện LSM thiết kế thủ công [342], công cụ phân tích mã nguồn xây dựng để xác minh tính đầy đủ [351] tính quán [149] giao diện LSM, tìm thấy sáu lỗi giao diện giải 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 cách rõ ràng [342], việc triển khai CIPSO (tức mạng gắn nhãn, xem Phần 7.5.2) 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ữ nhãn quán phân mảnh chống phân mảnh gói, khơng có sách bảo mật thực thi, điều tốn Có hai lựa chọn thay khác cho mạng gắn nhãn hỗ trợ hạt nhâ Linux Đầu tiên Labeled IPsec[148], dựa mạng có gắn nhãn Flask [50], thương lượng nhãn cho giao tiếp mạng IPsec tham số mật mã Mạng điều khiển LSM giao tiếp cách cho phép q trình sử dụng kênh giao tiếp IPsec cụ thể hay khơng Vì nhãn kênh IPsec thiết lập thời điểm thương lượng, nên khơng cần bao gồm nhãn gói Thứ hai, Paul Moore xây dựng triển khai CIPSO cho Linux, gọi Netlabel [214] Netlabel cung cấp phiên CIPSO xâm nhập chấp nhận cộng đồng Linux Khung mô-đun bảo mật Linux thức thêm vào nhân Linux với việc phát hành phiên 2.6 Mô-đun SELinux mô-đun để triển khai tính POSIX [307] bao gồm việc phát hành LSM Novell, nhà phân phối SuSE Linux, mua công ty hỗ trợ AppArmor, SuSE phân phối Linux khác hỗ trợ AppArmor LSM SELinux AppArmor trở thành LSM quan trọng Trong hai mang đến cho Linux cải tiến bảo mật, chuyển đổi Linux (hoặc hệ thống UNIX nào) thành hệ thống đáp ứng tham chiếu giám sát an tồn nhiệm vụ khó khăn Tuy nhiên, với việc Linus tái khẳng định ủng hộ LSM framework [188] vào năm 2006 nhiều nhà cung cấp Linux hỗ trợ đằng sau LSM, khung LSM coi thành công khiêm tốn 9.1.2 TRIỂN KHAI LSM Việc triển khai khung LSM bao gồm ba phần: (1) định nghĩa giao diện giám sát chuẩn; (2) vị trí giao diện giám sát chuẩn; (3) thân việc triển khai giám sát chuẩn Định nghĩa giao diện giám sát chuẩn LSM Định nghĩa giao diện LSM xác định cách mà nhân Linux gọi giám sát chuẩn LSM Tệp tiêu đề Linux include/linux/security.h liệt kê tập hợp trỏ hàm gọi hàm LSM tải Một cấu trúc nhất, gọi security_operations , chứa tất trỏ hàm LSM Chúng gọi chung trỏ chức móc LSM Về bản, móc LSM tương ứng với truy vấn ủy quyền LSM, giao diện LSM phải bao gồm móc LSM cho tác vụ LSM khác, chẳng hạn ghi nhãn, chuyển tiếp trì nhãn Hai ví dụ móc LSM thể bên 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 quy trình có LSM cho phép tạo tệp hay không, xác định dentry, thư mục dir cụ thể Móc LSM gọi thơng qua lệnh gọi đến trỏ hàm xác định security_ops-> inode_create LSM tải xác định cách ủy quyền thực Thứ hai, security_file_fcntl cho phép khả quy trình cụ thể để gọi fcntl tệp cụ thể Các móc LSM hàm do_fcntl cho phép LSM giới hạn số cách sử dụng fcntl cách độc lập (ví dụ: thiết lập trường fower báo hiệu trình liên quan hoạt động file) Tất có 150 móc LSM cho phép ủy quyền (như trên) hoạt động LSM khác nhãn, chuyển đổi nhãn bảo trì nhãn Mặc dù móc LSM khác nhằm phục vụ mục đích khác nhau, chúng có định dạng tương tự hai định dạng liệt kê Vị trí giao diện giám sát chuẩn LSM Thách thức việc thiết kế khung LSM vị trí móc LSM Hầu hết móc LSM liên kết với lệnh gọi hệ thống, móc LSM đặt đầu vào lệnh gọi hệ thống Tuy nhiên, số khơng thể đặt móc LSM điểm nhập lệnh gọi hệ thống (ví dụ: để ngăn cách cơng TOCTTOU, xem Chương 2) Ví dụ, Hình 9.1, lệnh gọi hệ thống open chuyển đổi tệp đường dẫn đến mô tả tệp cho phép truy cập (tức đọc và/hoặc ghi) vào tệp liên kết Vị trí tệp cụ thể mơ tả đường dẫn tệp yêu cầu cấp quyền truy cập vào thư mục truy cập dọc theo đường dẫn, liên kết file đường dẫn cuối ủy quyền cho tệp đích cụ thể hoạt động yêu cầu Vì thành phần trích xuất từ đường dẫn tệp điểm khác trình xử lý mở, nên vị trí móc LSM khơng quan trọng Mặc dù có số kiểm tra tuỳ ý giúp hướng dẫn vị trí móc LSM cho open, q trình mà móc LSM đặt phần lớn đặc biệt Đối với người khơng có ủy quyền tùy ý trước thực hiện, người triển khai thực vị trí thủ cơng Một số vị trí phát sai số hoạt động nhạy cảm bảo mật phát thiếu hòa giải, vấn đề giải thông qua phân tích mã nguồn [351, 149] Một móc LSM đặt mã cách sử dụng khai báo hàm nội tuyến (ví dụ: security_inode_create) mở rộng thời điểm biên dịch thành móc LSM hiển thị đoạn mã Các hàm nội tuyến cho móc LSM sử dụng để cải thiện khả đọc mã Triển khai giám sát chuẩn LSM Cuối cùng, LSM phải xây dựng để thực ủy quyền thực tế Các LSM thực tế bao gồm AppArmor [228], Hệ thống phát xâm nhập Linux (LIDS) [183], SELinux [229] Tính POSIX [307] Mỗi LSM cung cấp cách tiếp cận khác để kiểm soát truy cập bắt buộc, ngoại trừ tính POSIX vốn chế tùy ý có Linux Các khả POSIX chuyển đổi thành mô-đun phép phát triển độc lập từ nhân dịng số LSM nhằm thực điều khiển khả theo cách khác [342] Mặc dù Gasser Schell xác định sách nhân bảo mật khác yêu cầu giao diện giám sát tham chiếu khác (tức vị trí móc LSM khác nhau) [10] (trong ngữ cảnh nhân bảo mật, xem Chương 6), LSM sử dụng vị trí giống cho tất LSM Trong thực tế, việc lựa chọn vị trí móc LSM kết hợp giám sát chuẩn chuyển đến khung Việc triển khai LSM không yêu cầu LSM cung cấp triển khai cho hook, đó, phương pháp thống không yêu cầu nhà phát triển LSM phải làm thêm việc Tuy nhiên, móc LSM phần lớn ổn định 1000 nhãn kiểu xác định sách tham chiếu SELinux, trạng thái bảo vệ SELinux mặc định hàng chục nghìn câu lệnh allow cần thiết để thể tất mối quan hệ khác chủ thể đối tượng hệ thống Linux Trong mơ hình sách SELinux dẫn đến biểu diễn trạng thái bảo vệ phức tạp, độ phức tạp trạng thái bảo vệ kết phức tạp hệ thống Linux Linux bao gồm nhiều chương trình khác nhau, hầu hết có u cầu truy cập riêng biệt yêu cầu bảo mật riêng biệt, dẫn đến số lượng lớn nhãn kiểu Khi đó, số lượng lớn nhãn kiểu yêu cầu số lượng lớn câu lệnh allow để thể tất mối quan hệ truy cập cần thiết Chính sách tham chiếu SELinux thể chúng tơi chống lại cố gắng xây dựng hệ thống Linux an toàn 9.2.3 TRẠNG THÁI GHI NHÃN SELINUX Vì trạng thái bảo vệ SELinux xác định theo nhãn, điển hình sách truy cập bắt buộc, trạng thái bảo vệ phải ánh xạ tới tài nguyên hệ thống thực tế Mức độ khó tin phần trước khiến chúng tơi khó tin vì, chúng tơi đề cập số tệp định, chẳng hạn / etc / shadow có số nhãn định, chẳng hạn shadow_t, không rõ cách tệp thu nhãn từ đầu Hơn nữa, quy trình gán nhãn, chẳng hạn quy trình passwd có nhãn passwd_t ánh xạ nhãn tới quy trình phải xác định Các thông số kỹ thuật cung cấp mà gọi trạng thái ghi nhãn hệ thống bảo vệ bắt buộc Định nghĩa 2.4 Trạng thái gắn nhãn sách bất biến xác định cách quy trình tài nguyên hệ thống tạo gắn nhãn SELinux cung cấp bốn cách để xác định nhãn đối tượng Đầu tiên, đối tượng gắn nhãn dựa vị trí hệ thống tệp Giả sử tệp / etc / passwd / etc / shadow cung cấp gói Linux cho chương trình passwd Trong trường hợp này, tệp tồn số dạng cần gắn nhãn cài đặt SELinux sử dụng ngữ cảnh tệp để gắn nhãn tệp có tệp cung cấp 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 biểu thức quy mơ tả tập hợp 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 18 Ví dụ, định nghĩa ngữ cảnh tệp thứ hai xác định ngữ cảnh đối tượng cho tệp thư mục / etc / etc / shadow nhận ngữ cảnh đặc biệt tệp khác / etc (ví dụ: / etc / passwd) nhận ngữ cảnh mặc định Thứ hai, đối tượng tạo động, nhãn chúng kế thừa từ đối tượng mẹ chúng Đối với tệp, điều xác định thư mục mẹ Đối với tất tệp tạo động thư mục / etc, chúng kế thừa nhãn xác định cho thư mục, etc_t Thứ ba, quy tắc type_transition định sách SELinux ghi đè nhãn đối tượng mặc định Dưới đây, hiển thị quy tắc type_transition gắn nhãn lại tất tệp tạo quy trình với loại passwd_t 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 ý ngữ cảnh quy trình tạo phải ủy quyền để gắn nhãn lại tệp etc_t thành tệp passwd_t Nếu sử dụng quy trình passwd để tạo / etc / shadow, / etc có nhãn etc_t, gán nhãn shadow_t thay dựa quy tắc Trạng thái gắn nhãn SELinux thực thi mục tiêu bảo mật thông qua ngữ cảnh tệp quản trị viên định, nhãn mặc định quy tắc type_transition ủy quyền Trạng thái gắn nhãn cho phép kiểm sốt xác việc dán nhãn, khơng thiết đảm bảo mục tiêu bảo mật quán (tức luồng thơng tin) Phân tích bên ngồi cần thiết để xác định xem trạng thái ghi nhãn có đạt độ bảo mật mong muốn hay không, thảo luận phần đánh giá SELinux 9.2.4 TRẠNG THÁI CHUYỂN GIAO SELINUX Theo mặc định, quy trình gắn nhãn với nhãn quy trình gốc, mô tả trên, trạng thái chuyển tiếp SELinux cho phép chuyển đổi nhãn quy trình Nếu quy trình trình bao người dùng chạy với nhãn user_t, tất quy trình tạo từ trình bao chạy nhãn user_t Mặc dù điều có ý nghĩa nhiều chương trình, chẳng hạn trình chỉnh sửa, ứng dụng email trình duyệt web, số chương trình mà người dùng chạy cần quyền khác Ví dụ: chương trình mật cần quyền truy cập khơng phép chương trình người dùng điển hình, chẳng hạn quyền truy cập ghi vào / etc / passwd and read-write access to /etc/shadow 19 Các quy tắc type_transition SELinux sử dụng để thể chuyển đổi nhãn quy trình Như hình đây, cú pháp tương tự trường hợp gán nhãn đối tượng, ngữ nghĩa khác 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 định quy trình chạy nhãn cụ thể (tức loại chương trình) thực thi tệp có nhãn cụ thể, sau quy trình gắn nhãn lại thành loại kết Như trường hợp ghi nhãn đối tượng, chuyển đổi nhãn quy trình thực thi phải ủy quyền Điều 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 phép chuyển đổi thực thi tệp đó; (3) quy trình phải cấp phép để chuyển nhãn sang loại_kết Trong trường hợp trên, trình bao người dùng tự phân tách thực thi tệp mật Tại thời điểm thực thi, quy tắc type_transition gọi Trình giám sát tham chiếu SELinux truy xuất quy tắc cho phép điều kiện cần thiết để gọi quy tắc Nếu trình chuyển đổi cho phép, trình chạy nhãn passwd_t truy cập tệp / etc / passwd / etc / shadow cần Lưu ý chuyển đổi nhãn quy trình SELinux phép thực quy trình Khi quy trình thực thi, hình ảnh quy trình cũ thay hình ảnh xác định tệp thực thi, đó, ngữ cảnh quy trình định lại dựa hình ảnh Lưu ý có số chuyển tiếp từ quy trình cũ, chẳng hạn tập hợp mô tả tệp mở thực thi biến mơi trường quy trình, quy tắc chuyển tiếp SELinux giới hạn ngữ cảnh mà chuyển tiếp phép Ví dụ: chương trình phụ thuộc vào việc chạy với tập hợp biến mơi trường có tính tồn vẹn cao, cho phép chuyển đổi từ ngữ cảnh có tính tồn vẹn cao Trong trường hợp mật mã, chạy từ quy trình người dùng khơng đáng tin cậy, tệp thực thi mật mã phải tin cậy để bảo vệ khỏi đầu vào toàn vẹn thấp cung cấp thời điểm thực thi Chuyển đổi quy trình SELinux an tồn chuyển đổi quy trình UNIX truyền thống thông qua setuid theo số cách Đầu tiên, q trình chuyển đổi setuid ln dẫn đến trình chạy với đầy đủ đặc quyền hệ thống (tức trình gốc setuid) Trong SELinux, trình chuyển đổi sang nhãn cụ thể với quyền hạn chế xác định cho mục đích Thứ hai, UNIX cho phép bất 20 kỳ trình thực chương trình setuid Kết là, tất chương trình setuid dễ bị đầu vào độc hại từ lệnh gọi không đáng tin cậy Trong SELinux, ngữ cảnh mà theo tiến trình gọi bị giới hạn Ví dụ, quy tắc SELinux viết để đảm bảo ngữ cảnh đáng tin cậy thực thi chương trình có tất quyền Chuyển đổi SELinux so sánh với chuyển tiếp Đa phương, xem Chương Trong Đa phương, dấu ngoặc trịn giới hạn quy trình gây chuyển đổi nhãn quy trình cách thực thi mã đáng tin cậy Tuy nhiên, điều khiển SELinux chi tiết hơn, chúng xác định cấp độ chương trình riêng lẻ, khơng phải vịng bảo vệ Tuy nhiên, Multics định nghĩa khái niệm thức để đảm bảo miền bảo vệ bảo vệ khỏi đầu vào độc hại, người gác cổng SELinux khơng có khái niệm 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 cung cấp chế cho phép trình tự gắn nhãn lại tài nguyên hệ thống cách sử dụng lệnh setcon chsid tương ứng Đối với tài nguyên hệ thống, quy trình passwd gọi rõ ràng chsid để gắn nhãn lại / etc / shadow vào nhãn shadow_t Bất kỳ q trình SELinux biết yêu cầu gắn nhãn lại tệp, trình giám sát tham chiếu SELinux cho phép tất chuyển đổi Nghĩa là, passwd_t phải ủy quyền để gắn nhãn lại tệp passwd_t thành shadow_t 9.2.5 QUẢN TRỊ SELINUX Vì SELinux sử dụng sách kiểm soát truy cập bắt buộc (MAC), nên quản trị viên hệ thống sửa đổi trạng thái hệ thống bảo vệ Kết là, trạng thái nói chung tĩnh SELinux cung cấp hai chế để cập nhật hệ thống bảo vệ nó: (1) tải sách ngun khối (2) tải sách mơ- đun Trong hai trường hợp, việc cấu hình sách SELinux nhiệm vụ chuyên gia, số lượng nhỏ sách phát triển Chính sách nguyên khối Các trạng thái hệ thống bảo vệ SELinux truyền thống định nghĩa biểu diễn nhị phân, toàn diện, tạo từ câu lệnh sách (ví dụ: allow, type_transition, v.v.) mơ tả Checkpolicy trình biên dịch sách SELinux xây dựng tệp nhị phân sách Đối với sách ngun khối, hàng chục nghìn câu lệnh sách SELinux biên dịch thành tệp nhị phân có kích thước MB Chương trình đáng tin cậy load_policy cho phép quản trị viên tải trạng thái bảo vệ thay hoàn toàn trạng thái bảo vệ cũ load_policy sử dụng hệ thống tệp 21 Sysfs 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 nhân sử dụng Tất truy vấn ủy quyền kiểm tra dựa sách nhị phân Chính sách mơ-đun, Vì sách SELinux thực xác định cho chương trình Linux thân chương trình Linux cài đặt thơng qua gói, chế quản trị sách SELinux mở rộng để hỗ trợ sửa đổi gia tăng Các mô-đun sách SELinux xác định đóng góp trạng thái bảo vệ theo chương trình cụ thể Một nhị phân sách SELinux tồn diện xây dựng từ mơ-đun riêng lẻ Mơ- đun sách bao gồm bốn phần: (1) nhãn loại riêng cho phép quy tắc cho loại này; (2) đặc tả ngữ cảnh tệp xác định cách tệp gắn nhãn; (3) giao diện cho phép mơ- đun khác truy cập nhãn loại nó; (4) mơ-đun sử dụng giao diện mô-đun khác Định nghĩa nhãn kiểu, quy tắc cho phép ngữ cảnh tệp khơng khác so với sách ngun khối, mơ tả ví dụ trên, mơ-đun sách bổ sung thêm khái niệm giao diện mô-đun [324] Giao diện mô-đun, giống giao diện phương thức cơng khai chương trình hướng đối tượng, cung cấp điểm vào cho mô-đun khác để truy cập nhãn loại mơ-đun Ví dụ: định nghĩa giao diện định tập hợp quy tắc cho phép phép cho mơ-đun gọi giao diện Ví dụ, mơ-đun sách hạt nhân định nghĩa giao diện kernel_read_system_state (arg) nhãn kiểu gửi dạng đối số arg gán phép quy tắc cho phép truy cập đọc vào trạng thái hệ thống Mơđun sách định giao diện tập hợp giao diện mà sử dụng Mơ-đun chức sử dụng để tải mơ-đun vào tệp nhị phân sách SELinux Phát triển sách Ban đầu, hai loại sách SELinux phát triển: (1) sách nghiêm ngặt (2) sách có mục tiêu Chính sách nghiêm ngặt nhằm thực thi đặc quyền tất chương trình Linux, tối đa hóa khả bảo vệ cho phép chức hợp lý Chính sách nghiêm ngặt đưa hai thách thức việc triển khai Đầu tiên, hạn chế chương trình Linux mong đợi, dẫn đến việc số chương trình khơng chạy cách Thứ hai, sách nghiêm ngặt khơng thực thi mục tiêu thức bí mật tồn vẹn, sách cho phép lỗ hổng nghiêm trọng Nguyên tắc sách nhắm mục tiêu giới thiệu AppArmor LSM [228] xác định sách đặc quyền cho daemon đối mặt với 22 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 giới hạn nhiệm vụ định cấu hình sách hạn chế daemon đối diện với mạng, điều giúp đơn giản hóa việc biểu đạt sách gỡ lỗi Tuy nhiên, sách nhắm mục tiêu không bảo vệ hệ thống khỏi yếu tố đầu vào có tính tồ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ài đặt nhãn khác) Do đó, sách nhắm mục tiêu phù hợp với hệ thống máy chủ có phần mềm quản lý cẩn thận dễ bị ảnh hưởng yêu cầu mạng độc hại Trên thực tế, phân phối SELinux (ví dụ: RedHat) phân phối với sách SELinux nhắm mục tiêu Gần đây, sách SELinux thứ ba, sách tham chiếu, xác định [309] Chính sách tham chiếu cho phép quản trị viên xây dựng sách nhắm mục tiêu sách nghiêm ngặt từ tập hợp tệp sách Tệp cấu hình cho phép quản trị viên mô tả thông số kỹ thuật họ để xây dựng sách Chính sách tham chiếu bao gồm hỗ trợ MLS theo mặc định 9.2.6 CÁC CHƯƠNG TRÌNH TIN CẬY CỦA SELINUX Ngoài hoạt động quản trị viên để tải sách (tức load_policy semodule), có nhiều chương trình cấp người dùng khác tin cậy để định / thực thi yêu cầu bảo mật SELinux để hệ thống SELinux an tồn Các chương trình bao gồm chương trình xác thực (ví dụ: sshd) cần thiết để thiết lập ngữ cảnh chủ thể người dùng xác thực, dịch vụ hệ thống cần thiết để khởi động hệ thống (ví dụ: init) chương trình máy chủ phụ thuộc vào để thực thi sách SELinux hoạt động họ Các chương trình xác thực sửa đổi để hiểu ngữ cảnh SELinux Khi người dùng xác thực, chương trình thơng báo cho trình giám sát tham chiếu SELinux, định ngữ cảnh chủ đề thích hợp cho quy trình người dùng Các dịch vụ bootstrap hệ thống chủ yếu tin cậy chúng có quyền rộng cho phép chúng xâm phạm tính tồn vẹn sách / giám sát tham chiếu SELinux Các dịch vụ chạy với đặc quyền gần đầy đủ tin cậy không sửa đổi phá vỡ sách Ví dụ: quy trình sử dụng ngã ba / hành pháp UNIX truyền thống chúng khởi động dịch vụ hệ thống (ví dụ: vsftpd), để quy trình có quyền truy cập thích hợp thơng qua ghi nhãn quy trình (tức thơng qua quy tắc type_transition), mô tả 23 SELinux bao gồm số chương trình máy chủ sửa đổi để thực thi sách SELinux Một máy chủ mẫu máy chủ SELinux X [325] Máy chủ X cung cấp chế cho phép máy khách lấy thơng tin bí mật xâm phạm tính tồn vẹn máy khách khác Điều từ lâu biết đến vấn đề [85], số triển khai thực thi quyền truy cập cho hệ thống cửa sổ phát triển nhiều năm [90, 86, 42, 199, 289, 95] Cộng đồng SELinux xây dựng giao diện giám sát tham chiếu cho máy chủ X xác định máy chủ sách cấp người dùng trả lời truy vấn ủy quyền [43, 308] Thiết kế máy chủ sách nói chung hỗ trợ yêu cầu ủy quyền từ nhiều quy trình cấp người dùng, tương tự trình quản lý đối tượng Flask (xem Chương 7) Mục đích sách cấp người dùng xác minh để đảm bảo máy chủ đáng tin cậy thực thi sách tn thủ sách hệ thống SELinux Chính sách MLS SELinux chứa 30 loại chủ đề hệ thống tin cậy Trong nhiều trường hợp, loại chủ đề liên kết 1-1 với chương trình, số loại chủ đề, chẳng hạn init, có nhiều tập lệnh chạy loại đáng tin cậy Số lượng mã đáng tin cậy lớn, khó xác minh khả chống giả mạo xác minh tính đắn Chúng tơi lưu ý có số chương trình mà SELinux khơng tin tưởng Ví dụ: SELinux khơng tin tưởng NFS [267] để trả tệp cách an tồn Do đó, SELinux liên kết nhãn loại nfs_t cho tất tệp này, nhãn chúng máy chủ NFS Lý cho điều máy chủ NFS phân phối tệp cho máy khách cách rõ ràng, kẻ cơng trả lời tệp sai có yêu cầu NFS Các hệ thống tệp có giao tiếp bảo vệ tồn vẹn, chẳng hạn Hệ thống tệp Andrew kerberized [225, 234], tin cậy để cung cấp tệp 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 thiết kế [28, 2, 197, 104, 255, 314] Quy định chi tiết chủ đề nằm phạm vi sách 9.2.7 ĐÁNH GIÁ BẢO MẬT CỦA SELINUX Bây đánh giá liệu SELinux có đáp ứng yêu cầu hệ điều hành an tồn Chương SELinux cung cấp khn khổ mà yêu cầu đáp ứng (tức “an tồn” Multics) hay không, phức tạp hệ thống dựa UNIX gây khó khăn đảm bảo hồn tồn yêu cầu đáp ứng Hơn nữa, yêu cầu thực tế hệ thống UNIX (tức chức yêu cầu) giới hạn khả chúng tơi việc cấu hình hệ thống đáp ứng yêu cầu Do đó, SELinux cung cấp cải tiến bảo mật đáng kể so với hệ 24 thống UNIX truyền thống, (xem Chương 4), khó để định lượng cải tiến phạm vi yêu cầu hệ điều hành an toàn Hịa giải hồn chỉnh: Làm để giao diện giám sát chuẩn đảm bảo tất hoạt động nhạy cảm với bảo mật dàn xếp mà không tạo vấn đề bảo mật, chẳng hạn TOCTTOU? Giao diện giám sát tham chiếu khung Mô- đun bảo mật Linux thiết kế phép truy cập vào đối tượng thực tế nhân sử dụng hoạt động nhạy cảm với bảo mật để ngăn chặn lỗ hổng, chẳng hạn TOCTTOU Hịa giải hồn chỉnh: Giao diện giám sát chuẩn có dàn xếp hoạt động nhạy cảm bảo mật tất tài nguyên hệ thống không? Khung Mô-đun bảo mật Linux dàn xếp hoạt động xác định cộng đồng LSM để dẫn đến hoạt động nhạy cảm với bảo mật Dàn xếp cung cấp thực sự kết hợp tất nguyên mẫu giám sát chuẩn Linux xây dựng Hịa giải hồn chỉnh: Làm cách để xác minh giao diện 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 khung LSM thiết kế theo cách thức không thức, nên việc xác minh cung cấp dàn xếp hồn chỉnh cần thiết Các cơng cụ phân tích mã nguồn phát triển để xác minh cấu trúc liệu hạt nhân nhạy cảm với bảo mật dàn xếp [351] cách quán [149] lỗi giao diện giám sát chuẩn LSM tìm thấy sửa Tuy nhiên, cơng cụ mang tính ước lượng yêu cầu dàn xếp hoàn chỉnh chúng khơng áp dụng thường xun Tuy nhiên, khơng có lỗi vị trí giao diện giám sát chuẩn tìm thấy kể từ giới thiệu Linux 2.6 Chống giả mạo: Hệ thống bảo vệ giám sát chuẩn, bao gồm hệ thống bảo vệ, khỏi bị sửa đổi nào? Các giám sát chuẩn LSM, chẳng hạn SELinux, chạy vịng bảo vệ trình giám sát, chúng bảo vệ hạt nhân Mặc dù khung công tác LSM giao diện mô-đun, LSM biên dịch vào hạt nhân, chúng hoạt động thời điểm khởi động Nhân Linux truy cập lệnh gọi hệ thống, hệ thống tệp đặc biệt tệp thiết bị, việc truy cập vào chế phải đảm bảo chống giả mạo Trong trình xử lý gọi hệ thống Linux không cung cấp tính lọc đầu vào cấp độ cổng Multics, công việc thực để xác minh việc xử lý đầu vào hạt nhân cách sử dụng cơng cụ phân tích mã nguồn [154] Hơn nữa, hệ 25 thống Linux cung cấp nhiều hoạt động khác cho phép truy cập vào nhớ nhân Ví dụ, hệ thống tệp đặc biệt, chẳng hạn hệ thống tệp / proc hệ thống tệp sysfs, tệp thiết bị cho phép truy cập vào nhớ nhân thông qua tệp Trạng thái bảo vệ SELinux cấu hình để giới hạn quyền truy cập vào quy trình đáng tin cậy (tức quy trình có nhãn loại chủ đề đáng tin cậy) Chống giả mạo: Hệ thống bảo vệ hệ thống có bảo vệ chương trình sở máy tính đáng tin cậy khơng? Như mơ tả trên, tính chống giả mạo hệ thống SELinux yêu cầu chương trình cấp người dùng đáng tin cậy phải chống giả mạo Đánh giá sách SELinux cho thấy xác định tập hợp quy trình đáng tin cậy xác định sở tính tốn đáng tin cậy, bảo vệ chống giả mạo [150] Tuy nhiên, số quy trình đáng tin cậy phải tin cậy để tự bảo vệ khỏi số đầu vào có tính tồn vẹn thấp, đó, việc đáp ứng tính tồn vẹn luồng thơng tin cổ điển khơng nhận đầu vào có tính tồn vẹn thấp (ví dụ: bảo vệ tồn vẹn Biba [27]) khơng thực tế Một số dịch vụ SELinux đáng tin cậy (ví dụ: sshd vsftpd) chứng minh thực thi phiên yếu tính tồn vẹn ClarkWilson [54, 285] Có thể kiểm chứng được: Cơ sở cho tính đắn sở tính tốn đáng tin cậy hệ thống? Như điển hình, xác minh tính đắn việc thực thi an ninh nhiệm vụ khó đạt Xác minh tính đắn việc triển khai nhân Linux chương trình đáng tin cậy nhiệm vụ phức tạp Đối với sở mã lớn này, hầu hết viết ngơn ngữ an tồn khơng kiểu loại, nhiều nhà phát triển, việc xác minh khơng thể hồn thành thực tế Linux đảm bảo mức đánh giá Tiêu chí Chung EAL4 (xem Chương 12), yêu cầu tài liệu thiết kế mức thấp hạt nhân Chuyển đổi thiết kế cấp thấp thành mơ hình thuộc tính bảo mật xác minh nhiệm vụ khó khăn khơng thực tế để xác minh cách mã nguồn triển khai thiết kế cách xác Có thể kiểm chứng được: Hệ thống bảo vệ có thực thi mục tiêu bảo mật hệ thống khơng? Các sách SELinux xác định đặc tả xác, bắt buộc hoạt động phép hệ thống Do đó, xây dựng biểu diễn luồng thơng tin từ sách SELinux [150] (đã đề cập trên), chí biểu diễn bao gồm trạng thái chuyển tiếp Ngồi ra, sách MLS đảm bảo tính bí mật luồng thơng tin đáp ứng thuộc tính bảo mật đơn giản Tuy nhiên, phân tích tính tồn 26 vẹn sách MLS tiết lộ số lượng đáng kể loại chủ đề đáng tin cậy (trên 30 tính tồn vẹn 30 MLS, số trùng lặp) Do đó, phương pháp SELinux cho phép hệ thống “an toàn”, nhà phát triển hệ thống cần quản lý việc sử dụng mã đáng tin cậy cách cẩn thận để đảm bảo thực đáp ứng mục tiêu bảo mật xác minh 27 9.3 TỔNG KẾT Hệ thống LSM / SELinux thực giám sát chuẩn hệ điều hành Linux Cộng đồng LSM lên từ nhiều nỗ lực nguyên mẫu để thêm giám sát chuẩn vào Linux phát triển giao diện giám sát chuẩn cộng đồng bảo mật (phần lớn) cộng đồng Linux thống chấp nhận SELinux AppArmor LSM nhà phân phối Linux lớn áp dụng nhiều nhà phân phối khác hỗ trợ Mặc dù khung LSM thử nghiệm bán thức, nhìn chung bổ sung thành công cho hạt nhân Tuy nhiên, kết hợp hạt nhân Linux khung LSM phức tạp để có xác minh thức hồn chỉnh yêu cầu để chứng minh dàn xếp hoàn chỉnh chống giả mạo Thách thức làm để sử dụng giao diện giám sát chuẩn LSM để thực thi mục tiêu bảo mật Chúng kiểm tra hệ thống SELinux cung cấp dịch vụ tồn diện để thực sách bảo mật hệ thống bảo vệ chi tiết linh hoạt để kiểm sốt xác tất quy trình Các phương pháp tiếp cận SELinux cho thấy phức tạp hệ thống UNIX khó khăn việc thực thi bảo mật toàn diện Thách thức bật định nghĩa xác minh mục tiêu bảo mật mong muốn sách cấp thấp AppArmor LSM sử dụng sách nhắm mục tiêu để bảo vệ hệ thống khỏi tội phạm mạng, chứng việc thực thi mục tiêu bảo mật phải xác minh yêu cầu, chẳng hạn luồng thông tin 28 TÀI LIỆU THAM KHẢO M Abadi, E Wobber, M Burrows, and B Lampson Authentication in the Taos Operating System.InProceedings of the 14th ACM Symposium on Operating System Principles,pp.256–269, Asheville, NC, 1993 DOI: 10.1145/168619.168640 [13] Securitystarts with your operatingsystem http://www.argus systems.com/home3.shtml, 2008 [27] K J Biba Integrity considerations for secure computer systems Technical Report MTR- 3153, MITRE, April 1977 [28] A D Birrell, A Hisgen, C Jerian, T Mann, and G Swart The Echo distributed file system Technical Report 111, Digital Systems Research Center, September 1993 [42] M Carson, et al Secure window systems for UNIX In Proceedings of the USENIX Winter 1989 Conference, January 1989 [43] J Carter Using GConf as an example of how to create a userspace object manager In Proceedings of the 2007 SELinux Symposium Available at http://selinux-symposium.org/2007/agenda.php, March 2007 [50] A.Chitturi Implementing mandatory network security in a policyflexible system,April/June 1998 University of Utah, Master’s Thesis [54] D D Clark and D Wilson A comparison of military and commercial security policies In 1987 IEEE Symposium on Security and Privacy, May 1987 DOI: 10.1109/SP.1987.10001 [80] N Edwards, J Berger, and T H Choo A secure Linux platform In ALS ’01: Proceedings of the 5th Annual Conference on Linux Showcase & Conference, 2001 [86] J Epstein, et al Evolution of a Trusted B3 Window System prototype In Proceedings of the 1992 IEEE Symposium on Research in Security and Privacy, May 1992 DOI: 10.1109/RISP.1992.213258 [90] G Faden Reconciling CMW requirements with those of X11 applications In Proceedings of the 14th Annual National Computer Security Conference, October 1991 [95] N Feske and C Helmuth A nitpicker’s guide to a minimal-complexity secure GUI In Proceedings of the 21st Annual Computer Security Applications Conference, pp 85–94, 2005 DOI: 10.1109/CSAC.2005.7 [104] K Fu, M F Kaashoek, and D Mazières Fast and secure distributed read-only file system ACM Transactions on Computer Systems, 20(1):1–24, 2002 DOI: 10.1145/505452.505453 [112] GPL General Public License http://www.gnu.org/licenses/gpl.html, 2007 [2] 29 S E Hallyn and P Kearns Domain and type enforcement for Linux In Proceedings of the 4th Annual Linux Showcase and Conference At http://www.sagecertification.org/publications/library/proceedings/als0 0/2000papers/papers/full_papers/hallyn/hallyn_html/index.html, October 2000 [148] T Jaeger, K Butler, D H King, S Hallyn, J Latten, and X Zhang Leveraging IPsec for mandatory access control across systems In Proceedings of the Second International Conference on Security and Privacy in Communication Networks, August 2006 DOI: 10.1109/SECCOMW.2006.359530 [149] T.Jaeger,A.Edwards, and X.Zhang.Consistency analysis of authorization hook placement in the Linux security modules framework ACM Transactions on Information and System Security (TISSEC), 7(2):175–205, May 2004 DOI: 10.1145/996943.996944 [150] T Jaeger, R Sailer, and X Zhang Analyzing integrity protection in the SELinux example policy In Proceedings of the 12th USENIX Security Symposium, pp 59–74, August 2003 [154] R Johnson and D.Wagner Finding user/kernel pointer bugs with type inference In Proceedings of the 13th conference on USENIX Security Symposium, pp 9–9, 2004 [183] LIDS Secure Linux System http://www.lids.org/, 2008 [188] Kernel Summit 2006 - Security http://lwn.net/Articles/191737/, July 2006 [197] D Mazières, M Kaminsky, M F Kaashoek, and E Witchel Separating key management from file system security In Proceedings of the 17th ACM Symposium on Operating System Principles, pp 124–139, 1999 DOI: 10.1145/319344.319160 [199] D McIlroy and J Reeds Multilevel windows on a single-level terminal In Proceedings of the (First) USENIX Security Workshop, August 1988 [204] Medusa DS9 Security System http://medusa.terminus.sk/, 2008 [214] P Moore NetLabel – Explicit labeled networking for Linux http://netlabel.sourceforge.net/, October 2007 [225] B C Neuman and T.Ts’o Kerberos: An authentication service for computer networks IEEE Communications, 32(9):33–38, 1994 DOI: 10.1109/35.312841 [228] AppArmor Linux application security http://www.novell.com/linux/security/apparmor/, 2008 [229] Security-Enhanced Linux http://www.nsa.gov/selinux [234] OpenAFS http://www.openafs.org/, 2008 [235] OpenBSD http://www.openbsd.org/, 2008 [127] 30 OpenWall Project - Information security software for open environments http://www.openwall.com/, 2008 [239] A Ott RSBAC and LSM http://www.rsbac.org/documentation/why_rsbac_does_not_use_lsm, 2006 [240] A Ott RSBAC: Extending Linux security beyond the limits http://www.rsbac.org/, 2008 [255] P Reiher,T Page, S.Crocker,J.Cook, and G Popek.Truffles—a secure service for widespread file sharing In Proceedings of the The PSRG Workshop on Network and Distributed System Security, February 1993 [267] R Sandberg, D Goldberg, S Kleiman, D Walsh, and B Lyon Design and implementation of the Sun Network Filesystem In Proceedings of the 1985 Summer USENIX Conference, pp 119–130, 1985 [285] U Shankar,T Jaeger, and R Sailer.Toward automated information-flow integrity verification for security-critical applications In Proceedings of the 2006 ISOC Networked and Distributed Systems Security Symposium (NDSS’06), San Diego, CA, February 2006 [289] J S Shapiro, J Vanderburgh, E Northup, and D Chizmadia Design of the EROS trusted window system In Proceedings of the 13th conference on USENIX Security Symposium, 2004 [296] B Spengler grsecurity http://www.grsecurity.net/, 2008 [297] B Spengler grsecurity LSM http://www.grsecurity.net/lsm.php, 2008 [307] B Tobotras Linux kernel capabilities FAQ http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.txt, April 1999 [309] Reference Policy http://oss.tresys.com/projects/refpolicy, Tresys Corp., 2008 [314] A Vahdat Operating System Services for Wide-Area Applications PhD thesis, University of California, Berkeley, December 1998 [325] E Walsh Application of the Flask architecture to the X Window System server In Proceedings of the 2007 SELinux Symposium Available at http://selinuxsymposium.org/2007/agenda.php, March 2007 [342] C.Wright,C.Cowan,S.Smalley,J.Morris, and G.Kroah-Hartman.Linux Security Modules: General security support for the Linux kernel In Proceedings of the 11th USENIX Security Symposium, pp 17–31, August 2002 [351] X Zhang, A Edwards, and T Jaeger Using CQUAL for static analysis of authorization hook placement In Proceedings of the 11th USENIX Security Symposium, pp 33–48, San Francico, CA, August 2002 [236] 31 Phân công dịch 9.1 – 9.1.2: Nguyễn Hà Thiên Phong • 9.2 – 9.2.1: Nguyễn Thị Thuý Kiều • 9.2.2 – 9.2.3 • 9.2.4 -9.2.5 • 9.2.6 – hết • 32 ... pháp Mục tiêu đề tài nghiên cứu tìm hiểu chế bảo mật hệ điều hành Linux, qua thấy tầm quan trọng chế thực vấn đề bảo mật Nghiên cứu xây dựng hệ điều hành an toàn Linux Hệ điều hành Linux hoàn thiện... cao quan trọng Hệ điều hành Linux đời mang theo nhiều đặc tính an tồn bao hàm chế bảo mật, với tính chất mã nguồn mở đánh giá hệ điều hành bảo mật tốt Hơn nữa, Linux server thách thức lớn tình... vv…là lớn Vấn đề bảo đảm an ninh, an tồn cho thơng tin mạng ngày mối quan tâm hàng đầu công ty, tổ chức, nhà cung cấp dịch vụ Việc bảo vệ an toàn liệu vấn đề cấp thiết, việc lựa chọn hệ điều hành