SE Linux

SE Linux

SELinux administrator GUI in Fedora v8
Thiết kế bởi	NSA và Red Hat
Phát triển bởi	Red Hat
Phát hành lần đầu	22 tháng 12 năm 2000; 23 năm trước (2000-12-22)[1]
Phiên bản ổn định	2.9 / 15 tháng 3 năm 2019; 5 năm trước (2019-03-15)[2]
Kho mã nguồn	github.com/SELinuxProject/selinux
Viết bằng	C
Hệ điều hành	Linux
Thể loại	Security, Linux Security Modules (LSM)
Giấy phép	GNU GPL
Website	selinuxproject.org, nsa.gov/What-We-Do/Research/SELinux/

Security-Enhanced Linux (SELinux) là một module bảo mật của Linux kernel cung cấp một cơ chế hỗ trợ các chính sách bảo mật kiểm soát truy cập, bao gồm kiểm soát truy cập bắt buộc (MAC).

SELinux là một tập hợp các sửa đổi kernel và các công cụ không gian người dùng đã được thêm vào các bản phân phối Linux khác nhau. Kiến trúc của nó cố gắng tách biệt việc thực thi các quyết định bảo mật khỏi chính sách bảo mật và hợp lý hóa số lượng phần mềm liên quan đến thực thi chính sách bảo mật.^[3][4] Các khái niệm chính bên dưới SELinux có thể được Cơ quan An ninh Quốc gia Hoa Kỳ (NSA) truy tìm đến một số dự án trước đó.

Tổng quan

Từ Nhóm NSA Security-enhanced Linux:^[5]

NSA Security-Enhanced Linux là một tập hợp các bản vá cho Linux kernel và các tiện ích để cung cấp kiến trúc điều khiển truy cập (MAC) mạnh mẽ, linh hoạt, bắt buộc vào các hệ thống con chính của kernel. Nó cung cấp một cơ chế nâng cao để thực thi việc phân tách thông tin dựa trên các yêu cầu về bảo mật và toàn vẹn, cho phép các mối đe dọa giả mạo và bỏ qua các cơ chế bảo mật ứng dụng, được giải quyết và cho phép hạn chế thiệt hại có thể gây ra bởi các ứng dụng độc hại hoặc thiếu sót. Nó bao gồm một tập hợp các file cấu hình chính sách bảo mật mẫu được thiết kế để đáp ứng các mục tiêu bảo mật chung, mục đích chung

Một nhân Linux tích hợp SELinux thực thi các chính sách kiểm soát truy cập bắt buộc nhằm giới hạn các chương trình người dùng và dịch vụ hệ thống, cũng như truy cập vào các tệp và tài nguyên mạng. Giới hạn đặc quyền ở mức tối thiểu cần thiết để làm việc làm giảm hoặc loại bỏ khả năng của các chương trình và trình nền này gây hại nếu bị lỗi hoặc bị xâm phạm (ví dụ thông qua lỗi tràn bộ nhớ đệm hoặc cấu hình sai). Cơ chế giam cầm này hoạt động độc lập với các cơ chế kiểm soát truy cập Linux (Tùy chọn) truyền thống. Nó không có khái niệm về một siêu người dùng "root" và không chia sẻ những thiếu sót nổi tiếng của các cơ chế bảo mật Linux truyền thống, chẳng hạn như sự phụ thuộc vào các nhị phân setuid/setgid.

Tính bảo mật của hệ thống Linux "chưa sửa đổi" (hệ thống không có SELinux) phụ thuộc vào tính chính xác của hạt nhân, của tất cả các ứng dụng đặc quyền và của từng cấu hình của chúng. Một lỗi trong bất kỳ một trong những lĩnh vực này có thể cho phép sự thỏa hiệp của toàn bộ hệ thống. Ngược lại, tính bảo mật của hệ thống "được sửa đổi" (dựa trên kernel SELinux) phụ thuộc chủ yếu vào tính chính xác của kernel và cấu hình chính sách bảo mật của nó. Mặc dù các vấn đề về tính chính xác hoặc cấu hình của các ứng dụng có thể cho phép sự thỏa hiệp hạn chế của các chương trình người dùng và trình nền hệ thống riêng lẻ, nhưng chúng không nhất thiết gây ra mối đe dọa đối với bảo mật của các chương trình và trình nền hệ thống khác hoặc toàn bộ bảo mật của hệ thống.

Từ quan điểm thuần túy, SELinux cung cấp hỗn hợp các khái niệm và khả năng được rút ra từ các điều khiển truy cập bắt buộc, toàn vẹn bắt buộc, kiểm soát truy cập dựa trên vai trò (RBAC) và kiến trúc thực thi kiểu.

Lịch sử

Công việc sớm nhất hướng tới tiêu chuẩn hóa một cách tiếp cận cung cấp các điều khiển truy cập bắt buộc và tùy ý (MAC và DAC) trong môi trường điện toán UNIX (chính xác hơn là, POSIX) có thể được quy cho Trusted UNIX (TRUSIX) Working Group của NSA, với các buổi họp từ năm 1987 đến năm 1991 và xuất bản cuốn Rainbow Book (#020A), và tạo ra một mô hình chính thức và nguyên mẫu đánh giá bằng chứng liên quan (#020B) về cơ bản chưa được xuất bản.

SELinux được thiết kế để chứng minh giá trị của giá trị của các điều khiển truy cập bắt buộc đối với cộng đồng Linux và cách các điều khiển đó có thể được thêm vào Linux. Ban đầu, các bản vá tạo nên SELinux phải được áp dụng rõ ràng cho mã nguồn nhân Linux; SELinux đã được hợp nhất vào dòng chính của nhân Linux trong series 2.6 của nhân Linux

NSA, nhà phát triển chính ban đầu của SELinux, đã phát hành phiên bản đầu tiên cho cộng đồng phát triển nguồn mở theo GNU GPL ngày 22 tháng 12 năm 2000.^[6] Phần mềm đã được sáp nhập vào nhân Linux chính 2.6.0-test3, được phát hành vào ngày 8 tháng 8 năm 2003. Những người đóng góp đáng kể khác bao gồm Red Hat, Network Associates, Secure Computing Corporation, Tresys Technology, và Trusted Computer Solutions. Các port thử nghiệm của FLASK/TE đã được cung cấp thông qua TrustedBSD Project cho các hệ điều hành FreeBSD và Darwin.

SE Linux triển khai Flux Advanced Security Kernel (FLASK). Một hạt nhân như vậy chứa các thành phần kiến trúc được tạo mẫu trong hệ điều hành Fluke. Chúng cung cấp hỗ trợ chung để thực thi nhiều loại chính sách kiểm soát truy cập bắt buộc, bao gồm các chính sách dựa trên các khái niệm thực thi loại, kiểm soát truy cập dựa trên vai trò và bảo mật đa cấp.FLASK, lần lượt, dựa trên DTOS, Hệ điều hành tin cậy phân tán có nguồn gốc từ Mach, cũng như Trusted Mach, một dự án nghiên cứu từ Trusted Information Systems có ảnh hưởng đến việc thiết kế và triển khai DTOS

Người dùng, chính sách và bối cảnh bảo mật

Người dùng và vai trò của SElinux không phải liên quan đến người dùng và vai trò thực tế của hệ thống. Đối với mỗi người dùng hoặc quy trình hiện tại, SELinux chỉ định bối cảnh ba chuỗi bao gồm tên người dùng, vai trò và tên miền (hoặc kiểu). Hệ thống này linh hoạt hơn so với yêu cầu thông thường: theo quy định, hầu hết người dùng thực đều chia sẻ cùng tên người dùng SELinux và tất cả kiểm soát truy cập được quản lý thông qua thẻ thứ ba, tên miền. Các trường hợp theo đó một tiến trình được cho phép vào một tên miền nhất định phải được cấu hình trong các chính sách. Lệnh runcon cho phép khởi chạy một tiến trình vào một bối cảnh được chỉ định rõ ràng (người dùng, vai trò và miền), nhưng SELinux có thể từ chối quá trình chuyển đổi nếu nó không được chính sách chấp thuận.

Các file, cổng mạng và phần cứng khác cũng có ngữ cảnh SELinux, bao gồm tên, vai trò (hiếm khi được sử dụng) và loại. Trong trường hợp hệ thống file, ánh xạ giữa các file và ngữ cảnh bảo mật được gọi là ghi nhãn. Việc ghi nhãn được xác định trong các file chính sách nhưng cũng có thể được điều chỉnh thủ công mà không thay đổi chính sách. Các loại phần cứng khá chi tiết, ví dụ, bin_t (tất cả các file trong thư mục /bin) hoặc postgresql_port_t (cổng PostgreSQL, 5432). Ngữ cảnh SELinux cho một hệ thống file từ xa có thể được chỉ định rõ ràng tại thời điểm gắn kết.

SELinux thêm công tắc -Z vào các lệnh shell ls, ps và một số lệnh khác, cho phép nhìn thấy ngữ cảnh bảo mật của các file hoặc quá trình.

Các quy tắc chính sách điển hình bao gồm các quyền rõ ràng, ví dụ: miền mà người dùng phải sở hữu để thực hiện một số hành động nhất định với mục tiêu đã cho (đọc, thực thi hoặc, trong trường hợp cổng mạng, liên kết hoặc kết nối), v.v. Ánh xạ phức tạp hơn cũng có thể, liên quan đến vai trò và mức độ bảo mật.

Một chính sách điển hình bao gồm file ánh xạ (ghi nhãn), file quy tắc và file giao diện, xác định chuyển đổi tên miền. Ba file này phải được biên dịch cùng với các công cụ SELinux để tạo một file chính sách. File chính sách kết quả có thể được tải vào kernel để kích hoạt nó. Chính sách tải và dỡ bỏ không yêu cầu khởi động lại. Các file chính sách được viết bằng tay hoặc có thể được tạo từ công cụ quản lý SELinux thân thiện hơn với người dùng. Chúng thường được kiểm tra ở chế độ cho phép trước, trong đó vi phạm được ghi lại nhưng được phép. Công cụ audit2allow có thể được sử dụng sau này để tạo ra các quy tắc bổ sung mở rộng chính sách để cho phép tất cả các hoạt động hợp pháp của ứng dụng bị giới hạn.

Tính năng

Các tính năng của SELinux bao gồm:

• Xóa sạch chính sách khỏi thực thi
• Giao diện chính sách được xác định rõ
• Hỗ trợ cho các ứng dụng truy vấn chính sách và thực thi kiểm soát truy cập (ví dụ: crond chạy các công việc trong ngữ cảnh chính xác)
• Độc lập của các chính sách và ngôn ngữ chính sách cụ thể
• Độc lập của các định dạng và nội dung nhãn bảo mật cụ thể
• Nhãn riêng và điều khiển cho các đối tượng và dịch vụ kernel
• Hỗ trợ thay đổi chính sách
• Các biện pháp riêng biệt để bảo vệ tính toàn vẹn của hệ thống (loại tên miền) và bảo mật dữ liệu (bảo mật đa cấp)
• Chính sách linh hoạt
• Kiểm soát quá trình khởi tạo và kế thừa và thực hiện chương trình
• Kiểm soát hệ thống file, thư mục, file và mở file descriptor
• Kiểm soát sockets, tin nhắn và giao diện mạng
• Kiểm soát việc sử dụng "khả năng"
• Thông tin được lưu trong các quyết định truy cập thông qua Access Vector Cache (AVC)^[7]
• Chính sách từ chối mặc định (mọi thứ không được chỉ định rõ ràng trong chính sách đều không được phép)^[8][9][10]

Triển khai

SELinux được triển khai trên Android từ phiên bản 4.3.^[11]

Trong số các bản phân phối GNU/Linux tự do được cộng đồng hỗ trợ, Fedora là một trong những bản chấp nhận sớm nhất, bao gồm hỗ trợ cho nó theo mặc định kể từ Fedora Core 2. Các bản phân phối khác bao gồm hỗ trợ cho nó như Debian từ bản phát hành Stretch^[12] và Ubuntu từ 8.04 Hardy Heron.^[13] Kể từ phiên bản 11.1, openSUSE chứa "sự hỗ trợ cơ bản" của SELinux.^[14] SUSE Linux Enterprise 11 có tính năng SELinux như một "bản xem trước công nghệ".^[15]

SELinux phổ biến trong các hệ thống dựa trên linux container, ví dụ như CoreOS Container Linux và rkt.^[16] Nó rất hữu ích như một kiểm soát bảo mật bổ sung để giúp thực thi thêm sự cô lập giữa các container được triển khai và máy chủ của chúng.

SELinux có sẵn từ năm 2005 như một phần của Red Hat Enterprise Linux (RHEL) version 4 và các bản phát hành trong tương lai. Sự hiện diện này cũng được phản ánh trong các phiên bản tương ứng của CentOS và Scientific Linux. Chính sách được hỗ trợ trong RHEL4 là chính sách được nhắm mục tiêu nhằm dễ sử dụng tối đa và do đó không hạn chế như có thể. Các phiên bản tương lai của RHEL được lên kế hoạch để có nhiều mục tiêu hơn trong chính sách được nhắm mục tiêu, điều đó có nghĩa là các chính sách hạn chế hơn.

Sử dụng các kịch bản

SELinux có khả năng kiểm soát các hoạt động mà một hệ thống cho phép mỗi người dùng, tiến trình và trình nền, với các thông số kỹ thuật rất chính xác. Nó được sử dụng để giới hạn các trình tiện ích như công cụ cơ sở dữ liệu hoặc máy chủ web có quyền truy cập dữ liệu và quyền hoạt động được xác định rõ ràng. Điều này hạn chế tác hại tiềm tàng từ một daemon bị giới hạn trở nên bị xâm phạm.

Các tiện ích dòng lệnh bao gồm:^[17] chcon,^[18] restorecon,^[19] restorecond,^[20] runcon,^[21] secon,^[22] fixfiles,^[23] setfiles,^[24] load_policy,^[25] booleans,^[26] getsebool,^[27] setsebool,^[28] togglesebool^[29] setenforce, semodule, postfix-nochroot, check-selinux-installation, semodule_package, checkmodule, selinux-config-enforcing,^[30] selinuxenabled,^[31] và selinux-policy-upgrade^[32]

Ví dụ

Để đưa SELinux vào chế độ thực thi:

$ sudo setenforce 1

Để truy vấn trạng thái SELinux:

$ getenforce

So sánh với AppArmor

SELinux đại diện cho một trong một số cách tiếp cận có thể đối với vấn đề hạn chế các hành động mà phần mềm đã cài đặt có thể thực hiện. Một lựa chọn phổ biến khác được gọi là AppArmor và có sẵn trên SUSE Linux Enterprise Server (SLES), openSUSE, và các nền tảng dựa trên Debian. AppArmor được phát triển như một thành phần của nền tảng Immunix Linux hiện không còn tồn tại. Vì AppArmor và SELinux khác nhau hoàn toàn, chúng tạo thành các lựa chọn thay thế khác nhau để kiểm soát phần mềm. Trong khi SELinux định nghĩa lại một số khái niệm nhất định để cung cấp quyền truy cập vào một tập hợp các lựa chọn chính sách rõ ràng hơn, AppArmor được thiết kế đơn giản bằng cách mở rộng cùng một ngữ nghĩa quản trị được sử dụng cho DAC đến mức kiểm soát truy cập bắt buộc.

Có một số khác biệt chính:

• Một sự khác biệt quan trọng là AppArmor xác định các đối tượng hệ thống file theo tên đường dẫn thay vì inode. Điều này có nghĩa là một file không thể truy cập được có thể truy cập được dưới AppArmor khi liên kết cứng được tạo với nó, trong khi đó, Selinux sẽ từ chối truy cập thông qua liên kết cứng mới được tạo.
  • Kết quả là, AppArmor có thể nói không phải là một hệ thống thực thi kiểu, vì các file không được gán một kiểu; thay vào đó, chúng chỉ được tham chiếu trong một file cấu hình.
• SELinux và AppArmor cũng khác nhau đáng kể về cách chúng được quản lý và cách chúng tích hợp vào hệ thống.^[33]
• Do nỗ lực tái tạo các điều khiển DAC truyền thống với thực thi cấp MAC, nên bộ hoạt động của AppArmor cũng nhỏ hơn đáng kể so với các hoạt động có sẵn trong hầu hết các triển khai của Selinux. Ví dụ: tập hợp các hoạt động của AppArmor bao gồm: đọc, viết, nối, thực thi, khóa và liên kết.^[34] Hầu hết các triển khai SELinux sẽ hỗ trợ số lượng yêu cầu hoạt động lớn hơn. Ví dụ: SELinux thường sẽ hỗ trợ các quyền tương tự, nhưng cũng bao gồm các điều khiển cho mknod, liên kết với các ổ cắm mạng, sử dụng ngầm các khả năng POSIX, tải và dỡ bỏ các mô-đun hạt nhân, các phương tiện khác nhau để truy cập bộ nhớ chia sẻ, v.v.
• Không có kiểm soát nào trong AppArmor cho các khả năng POSIX bị ràng buộc về mặt phân loại. Do việc triển khai các khả năng hiện tại không có khái niệm về một chủ đề cho hoạt động (chỉ có tác nhân và hoạt động), nên thường là công việc của lớp MAC để ngăn chặn các hoạt động đặc quyền trên các file bên ngoài phạm vi kiểm soát được thực thi của diễn viên (tức là "Sandbox"). AppArmor có thể ngăn chính sách của chính mình bị thay đổi và ngăn hệ thống tệp không được gắn kết / không bị chặn, nhưng không có gì ngăn người dùng bước ra ngoài phạm vi kiểm soát đã được phê duyệt của họ.
  • Ví dụ, có thể được coi là có lợi cho nhân viên của bộ phận trợ giúp để thay đổi quyền sở hữu hoặc quyền trên một số tệp nhất định ngay cả khi họ không sở hữu chúng (ví dụ: trên chia sẻ file của bộ phận). Rõ ràng là bạn không muốn cung cấp quyền người dùng root trên hộp để bạn cung cấp cho họ CAP_FOWNER hoặc CAP_DAC_OVERRIDE. Trong SELinux, bạn (hoặc nhà cung cấp nền tảng của bạn) có thể định cấu hình SELinux để từ chối tất cả các khả năng đối với người dùng không được kiểm soát, sau đó tạo các miền hạn chế để nhân viên có thể chuyển sang sau khi đăng nhập, một trong những có thể thực hiện các khả năng đó, nhưng chỉ trên các file của loại phù hợp.
• Không có khái niệm về bảo mật đa cấp với AppArmor, do đó không có triển khai BLP hay Biba cứng.
• AppArmor được thực hiện bằng cách sử dụng các file flat thông thường. SELinux theo mặc định trong hầu hết các triển khai) sử dụng kết hợp các file flat (được quản trị viên và nhà phát triển sử dụng để viết chính sách có thể đọc được của con người trước khi được biên dịch) và các thuộc tính mở rộng.
• SELinux hỗ trợ khái niệm "máy chủ chính sách từ xa" (có thể định cấu hình qua /etc/selinux/semanage.conf) làm nguồn thay thế cho cấu hình chính sách. Quản lý trung tâm của AppArmor thường phức tạp đáng kể vì các quản trị viên phải quyết định giữa các công cụ triển khai cấu hình được chạy dưới quyền root (để cho phép cập nhật chính sách) hoặc được định cấu hình thủ công trên mỗi máy chủ.

Các hệ thống tương tự

Cô lập các quy trình cũng có thể được thực hiện bằng các cơ chế như ảo hóa; dự án OLPC, ví dụ, trong lần đầu tiên triển khai các ứng dụng riêng lẻ ^[35] được đóng hộp trong các Vservers gọn nhẹ. Ngoài ra, NSA đã áp dụng một số khái niệm SELinux trong Security-Enhanced Android.^[36]

General Dynamics xây dựng và phân phối PitBull Trusted Computing Platform, một cải tiến bảo mật đa cấp cho Red Hat Enterprise Linux.

Xem thêm

• Unix security
• AppArmor
• Grsecurity
• Rule Set Based Access Control (RSBAC)
• Simplified Mandatory Access Control Kernel
• Solaris Trusted Extensions
• Tomoyo
• TrustedBSD
• Qubes OS

Chú thích

1. “Security-enhanced Linux available at NSA site - MARC”. MARC. Truy cập ngày 24 tháng 12 năm 2018.
2. “SELinux userspace release 20190315 / 2.9”. SELinux Project. ngày 15 tháng 3 năm 2019. Truy cập ngày 17 tháng 3 năm 2013.
3. “SELinux Frequently Asked Questions (FAQ) - NSA/CSS”. National Security Agency. Bản gốc lưu trữ ngày 18 tháng 9 năm 2018. Truy cập ngày 6 tháng 2 năm 2013.
4. Loscocco, Peter; Smalley, Stephen (tháng 2 năm 2001). “Integrating Flexible Support for Security Policies into the Linux Operating System” (PDF).
5. “Security-Enhanced Linux - NSA/CSS”. National Security Agency. ngày 15 tháng 1 năm 2009. Bản gốc lưu trữ ngày 19 tháng 7 năm 2019. Truy cập ngày 6 tháng 2 năm 2013.
6. Compare “National Security Agency Shares Security Enhancements to Linux”. NSA Press Release. Fort George G. Meade, Maryland: National Security Agency Central Security Service. ngày 2 tháng 1 năm 2001. Bản gốc lưu trữ ngày 20 tháng 2 năm 2018. Truy cập ngày 17 tháng 11 năm 2011. The NSA is pleased to announce that it has developed, and is making available to the public, a prototype version of a security-enhanced Linux operating system.
7. Fedora Documentation Project (2010). Fedora 13 Security-Enhanced Linux User Guide. Fultus Corporation. tr. 18. ISBN 978-1-59682-215-3. Truy cập ngày 22 tháng 2 năm 2012. SELinux decisions, such as allowing or disallowing access, are cached. This cache is known as the Access Vector Cache (AVC). Caching decisions decreases how often SELinux rules need to checked, which increases performance.
8. “SELinux/Quick introduction - Gentoo Wiki”. wiki.gentoo.org.
9. “Getting Started with SELinux”. Linode Guides & Tutorials (bằng tiếng Anh).
10. “NB Overview - SELinux Wiki”. selinuxproject.org.
11. “Security-Enhanced Linux in Android”. Android Open Source Project. Truy cập ngày 31 tháng 1 năm 2016.
12. “SELinux”. debian.org.
13. “How To Install SELinux on Ubuntu 8.04 "Hardy Heron"”. Ubuntu Tutorials.
14. “openSUSE News”. openSUSE News.
15. “Release Notes for SUSE Linux Enterprise Desktop 11”. Novell. Truy cập ngày 6 tháng 2 năm 2013.
16. “SELinux on CoreOS”. CoreOS Docs. Bản gốc lưu trữ ngày 26 tháng 9 năm 2018. Truy cập ngày 25 tháng 9 năm 2019.
17. “SELinux/Commands - FedoraProject”. Truy cập ngày 25 tháng 11 năm 2015.
18. “chcon”. Linuxcommand.org. Bản gốc lưu trữ ngày 24 tháng 10 năm 2004. Truy cập ngày 6 tháng 2 năm 2013.
19. “restorecon(8) - Linux man page”. Linux.die.net. Truy cập ngày 6 tháng 2 năm 2013.
20. “restorecond(8) - Linux man page”. Linux.die.net. Truy cập ngày 6 tháng 2 năm 2013.
21. “runcon(1) - Linux man page”. Linux.die.net. Truy cập ngày 6 tháng 2 năm 2013.
22. “secon(1) - Linux man page”. Linux.die.net. Truy cập ngày 6 tháng 2 năm 2013.
23. “fixfiles(8): fix file SELinux security contexts - Linux man page”. Linux.die.net. Truy cập ngày 6 tháng 2 năm 2013.
24. “setfiles(8): set file SELinux security contexts - Linux man page”. Linux.die.net. Truy cập ngày 6 tháng 2 năm 2013.
25. “load_policy(8) - Linux man page”. Linux.die.net. Truy cập ngày 6 tháng 2 năm 2013.
26. “booleans(8) - Linux man page”. Linux.die.net. Truy cập ngày 6 tháng 2 năm 2013.
27. “getsebool(8): SELinux boolean value - Linux man page”. Linux.die.net. Truy cập ngày 6 tháng 2 năm 2013.
28. “setsebool(8): set SELinux boolean value - Linux man page”. Linux.die.net. Truy cập ngày 6 tháng 2 năm 2013.
29. “togglesebool(8) - Linux man page”. Linux.die.net. Truy cập ngày 6 tháng 2 năm 2013.
30. “Ubuntu Manpage: selinux-config-enforcing - change /etc/selinux/config to set enforcing”. Canonical Ltd. Bản gốc lưu trữ ngày 20 tháng 12 năm 2012. Truy cập ngày 6 tháng 2 năm 2013.
31. “Ubuntu Manpage: selinuxenabled - tool to be used within shell scripts to determine if”. Canonical Ltd. Bản gốc lưu trữ ngày 9 tháng 2 năm 2013. Truy cập ngày 6 tháng 2 năm 2013.
32. “Ubuntu Manpage: selinux-policy-upgrade - upgrade the modules in the SE Linux policy”. Canonical Ltd. Bản gốc lưu trữ ngày 4 tháng 4 năm 2012. Truy cập ngày 6 tháng 2 năm 2013.
33. “SELinux backgrounds”. SELinux. Security Guide. SUSE.
34. “apparmor.d - syntax of security profiles for AppArmor”. Bản gốc lưu trữ ngày 17 tháng 10 năm 2013.
35. “Rainbow”. laptop.org.
36. “SELinux Related Work”. NSA.gov. Bản gốc lưu trữ ngày 20 tháng 2 năm 2018. Truy cập ngày 25 tháng 9 năm 2019.

Liên kết ngoài

• Website chính thức
• NSA:
  • SELinux FAQs Lưu trữ 2019-09-18 tại Wayback Machine
  • Security-Enhanced Linux Lưu trữ 2019-07-19 tại Wayback Machine at NSA
  • Mailing list Lưu trữ 2018-09-18 tại Wayback Machine
  • “NSA shares security enhancements to Linux”. Press release. 2 tháng 1 năm 2001. Bản gốc lưu trữ ngày 20 tháng 2 năm 2018. Truy cập ngày 25 tháng 9 năm 2019.
• SELinux trên GitHub
• Walsh, Daniel J (13 tháng 11 năm 2013). “Visual how-to guide for SELinux policy enforcement”. Opensource.com.