1.3 Một số cơ chế điều khiển truy cập trong SELinux: 1.3.1 Phương thức kiểm soát việc truy cập tài nguyên theo kiểu tùy quyền - Dicretionary Access Control DAC Điều khiển truy cập tùy
Trang 1HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG
CƠ SỞ TẠI TP HỒ CHÍ MINH KHOA CÔNG NGHỆ THÔNG TIN II
BÁO CÁO BẢO MẬT THÔNG TIN
(SELinux)
Giáo viên hướng dẫn : Thầy Lê Phúc Nhóm thực hiện : _Ngô Phi Công
_Trương Công Khá _Hoàng Phi Long
TP Hồ Chí Minh-11/2009
Trang 2I- TỔNG QUAN VỀ SELINUX:
1.1 SELinux là gì?
SeLinux là các phiên bản Linux có gia cố thêm hệ thống bảo mật của Hệ điều hành Nghĩa là nó vẫn là một phiên bản linux bình thường như Redhat hay Fedora Core nhưng có cài đặt thêm hệ thống Security Enhanced SELinux xây dựng cơ chế ràng buộc (security enforcement) chặt chẽ hơn, thông qua hệ thống chính sách bảo mật (security policy) được định nghĩa dựa trên các khái niệm của các mô hình Access control như MAC, DAC, RBAC
1.2 Lịch sử hình thành SELinux:
Năm 1973, hai ông David Bell và Leonard LaPadula đã trình bày ra một khái niệm về một hệ thống đa mức security, dựa vào các khái niệm này đến cuối thập niên 80, chính phủ Mỹ mới phát triển ra Trusted Computer System Evaluation Criteria (TCSEC) TCSEC định nghĩa ra 6 mức để phân cấp security cho hệ thống đó là C1, C2, B1, B2, B3, và A1 Trong đó các mức security C1 và C2 tương ứng với cơ chế DAC, các mức từ B1 trở lên tương ứng với cơ chế MAC hay cao hơn Trong thập niên 90, các chuyên gia của Cục An ninh Quốc gia Mỹ (NSA) phối hợp với Secure Computing Corporation (công ty này hiện giờ đang phát triển loại firewall có sử dụng cơ chế MAC thường được dùng cho các
tổ chức quân sự và quốc phòng của Mỹ xây dựng nên một cơ chế dymanic security policies gọi là Flask được phát triển lên từ project Fluke Sau đó NSA phối hợp với Network Associates và MITRE để đưa cơ chế Flask vào trong Linux, và chính thức công bố SELinux vào tháng 12 năm 2000
Đến thời điểm hiện nay, SELinux đã được Redhat và SuSe đưa vào trong các bản phân phối riêng của mình, ví dụ như Redhat Enterprise Linux 4.0 với SELinux được thực hiện theo cách riêng của Redhat gọi là "targeted" cấu hình sẵn cho các dịch vụ như Apache http, Bind Named DNS, Squid web caching services… Khi sử dụng cơ chế SELinux cho các dịch vụ Internet này thì hệ thống
sẽ vô cùng an toàn, và vấn đề lo ngại về chiếm quyền kiểm soát toàn bộ hệ thống thông qua các security bugs của các public Internet services đã được loại trừ
1.3 Một số cơ chế điều khiển truy cập trong SELinux:
1.3.1 Phương thức kiểm soát việc truy cập tài nguyên theo kiểu tùy quyền
- Dicretionary Access Control (DAC)
Điều khiển truy cập tùy quyền - DAC là một chính sách truy cập mà chủ nhân của tập tin hay người chủ của một tài nguyên nào đấy tự định đoạt Chủ nhân của nó quyết định ai là người được phép truy cập tập tin và những đặc
quyền (privilege) nào là những đặc quyền người đó được phép thi hành
Ví dụ như root có toàn quyền truy cập hệ thống và thâm nhập vào tất cả mọi tài nguyên của mọi users, theo cách thức này nếu một chương trình hay process
Trang 3nào đó chạy dưới quyền root mà bị khai thác lỗi và bị đoạt quyền kiểm soát thì xem như toàn bộ tài nguyên hệ thống bị kiểm soát
Hai quan niệm quan trọng trong truy cập tùy quyền là:
- Quyền sở hữu tập tin và dữ liệu (File and data ownership): Bất cứ một đối
tượng nào trong một hệ thống cũng phải có một chủ nhân là người sở hữu nó Chính sách truy cập các đối tượng là do chủ nhân tài nguyên quyết định - những tài nguyên bao gồm: các tập tin, các thư mục, dữ liệu, các tài nguyên của hệ thống Theo lý thuyết, đối tượng nào không có chủ sở hữu thì đối tượng đó bị bỏ
lơ, không được bảo vệ Thông thường thì chủ nhân của tài nguyên chính là người
đã kiến tạo nên tài nguyên (như tập tin hoặc thư mục)
- Các quyền và phép truy cập: Đây là những quyền khống chế những thực
thể tài nguyên mà chủ nhân của tài nguyên chỉ định cho mỗi một người hoặc mỗi một nhóm người dùng
Điều khiển truy cập tùy quyền có thể được áp dụng thông qua nhiều kỹ thuật khác nhau:
+ Danh sách điều khiển truy cập (Access control list - ACL) định danh các
quyền và phép được chỉ định cho một chủ thể hoặc một đối tượng Danh sách điều khiển truy cập cho ta một phương pháp linh hoạt để áp dụng quy chế điều khiển truy cập tùy quyền
+ Kiểm tra truy cập trên cơ sở vai trò (role-based access control) chỉ định tư
cách nhóm thành viên dựa trên vai trò của tổ chức hoặc chức năng của các vai trò Chiến lược này giúp tối giảm việc điều hành quản lý quyền và phép truy cập
1.3.2 Phương thức kiểm soát việc truy cập tài nguyên theo kiểu phân định quyền do hệ thống áp đặt - Mandatory Access Control (MAC):
SELinux tăng cường thêm cho cơ chế DAC với phương sách kiểm soát việc truy cập tài nguyên do hệ thống áp đặt (MAC) Theo cách này mỗi process hay chương trình đang chạy bị ép vào một khu vực giới hạn (domain) và sẽ không thể nào đi ra ngoài giới hạn đó được Như vậy khi một process hay chương trình bị khai thác lỗi và bị đoạt được quyền kiểm soát thì nó chỉ bị ảnh hưởng trong giới hạn biệt lập đó thôi chứ toàn bộ hệ thống sẽ không bị ảnh hưởng
Các đặc điểm cơ bản của MAC khi tăng cường cho DAC như sau:
- MAC phân định quyền truy cập tài nguyên ngay cả đến mức chương trình hay process, so với DAC chỉ áp đặt quyền truy cập tài nguyên chỉ dựa vào quyền hạn chức năng của users
- Nếu MAC đã áp đặt vào một tài nguyên nào nó thì ngay cả chủ sở hữu (owner) của tài nguyên đó cũng không thể gạt bỏ nó đi được
Như vậy, nhờ cơ chế này nếu một chương trình hay process nào đó chạy dưới quyền root mà bị khai thác lỗi và bị đoạt quyền kiểm soát thì người tấn công chỉ kiểm soát được những gì mà MAC áp đặt cho khu vực giới hạn của chương
Trang 4trình hay process đó đang chạy mà không thể đụng chạm sang các khu vực khác được, giảm thiểu được tác hại lên toàn bộ hệ thống
Hai khái niệm quan trọng trong cơ chế MAC là:
+ Nhãn hiệu nhạy cảm (sensitivity label): Trong hệ thống dùng điểu khiển
truy cập bắt buộc, hệ thống chỉ định một nhãn hiệu cho mỗi chủ thể (subject) và mỗi đối tượng (object) trong hệ thống Nhãn hiệu nhạy cảm của một chủ thể xác định mức tin cẩn cần thiết để truy cập
+ Xuất ngoại và nhập nội dữ liệu (Data import and export): Điều khiển việc
nhập nội thông tin từ một hệ thống khác và xuất ngoại thông tin sang các hệ thống khác là một chức năng trọng yếu trong các hệ thống sử dụng điều khiển truy cập bắt buộc Nhiệm vụ của việc xuất nhập thông tin là phải đảm bảo các nhãn hiệu nhạy cảm được giữ gìn một cách đúng đắn và nhiệm vụ này phải được thực hiện sao cho các thông tin nhạy cảm phải được bảo vệ trong bất kỳ tình huống nào
Có hai phương pháp được dùng phổ biến để áp dụng nguyên tắc điều khiển truy cập bắt buộc:
* Điều khiển truy cập dùng chính sách (role-based access control): Việc điều khiển thuộc loại này định nghĩa thêm những điều kiện cụ thể đối với việc truy cập một đối tượng mà chúng ta yêu cầu Tất cả các hệ thống dùng điều khiển truy cập bắt buộc đều thực hiện một hình thức đã được đơn giản hóa của thể loại điều khiển truy cập dùng chính sách, nhằm quyết định cho phép hay từ chối yêu cầu truy cập, bằng cách đối chiếu nhãn hiệu nhạy cảm của chủ thể và đối tượng
* Điều khiển truy cập dùng bố trí mắt lưới (lattice-based access control):
Đây là phương pháp người ta sử dụng đối với những quyết định phức tạp trong điều khiển truy cập với sự liên quan bội số các đối tượng và chủ thể Mô hình mắt
lưới là một cấu trúc toán học, nó định nghĩa các giá trị cận dưới lớn nhất (greatest lower-bound) và cận trên nhỏ nhất (least upper-bound) cho những cặp nguyên tố,
chẳng hạn như cặp nguyên tố bao gồm một chủ thể và một đối tượng
1.3.3 Phương thức kiểm soát việc truy cập tài nguyên trên cơ sở vai trò - Role-Based Access Control (RBAC)
Trong an ninh đối với các hệ thống máy tính, điều khiển truy cập trên cơ sở vai trò là một trong số các phương pháp điều khiển và đảm bảo quyền sử dụng cho người dùng RBAC khác với hình thức MAC và DAC truyền thống MAC và DAC trước đây là hai mô hình duy nhất được phổ biến trong điều khiển truy cập Nếu một hệ thống không dùng MAC thì người ta chỉ có thể cho rằng hệ thống đó dùng DAC, hoặc ngược lại Song cuộc nghiên cứu trong những năm 1990 đã chứng minh rằng RBAC không phải là MAC hoặc DAC
Trang 5Trong nội bộ một tổ chức, các vai trò (roles) được kiến tạo để đảm nhận các chức năng công việc khác nhau Mỗi vai trò được gắn liền với một số quyền hạn cho phép nó thao tác một số hoạt động cụ thể ('permissions')
Vì người dùng không được cấp phép một cách trực tiếp, song chỉ tiếp thu được những quyền hạn thông qua vai trò của họ, việc quản lý quyền hạn của người dùng trở thành một việc đơn giản, và người ta chỉ cần chỉ định những vai trò thích hợp cho người dùng mà thôi
RBAC khác với các danh sách điều khiển truy cập (Access control list - ACL) được dùng trong hệ thống điều khiển truy cập tùy quyền (DAC), ở chỗ, nó chỉ định các quyền hạn tới từng hoạt động cụ thể với ý nghĩa trong cơ quan tổ chức, thay vì tới các đối tượng dữ liệu hạ tầng Chẳng hạn, một danh sách điều khiển truy cập có thể được dùng để cho phép hoặc từ chối quyền truy cập viết một tập tin hệ thống (system file), song nó không nói cho ta biết phương cách cụ thể để thay đổi tập tin đó Việc chỉ định quyền hạn cho phép thi hành một thao tác nhất định là một việc làm đầy ý nghĩa, vì các thao tác đã được phân định tinh
tế và mỗi cá nhân thao tác có một ý nghĩa riêng trong chương trình ứng dụng
1.4 Mô hình hoạt động của SELinux:
Khi một chủ thể (chẳng hạn như một ứng dụng, tiến trình), thử truy cập vào một đối tượng (chẳng hạn như tập tin, thiết bị), máy chủ dùng để thi hành các chính sách (policy enforcement server) trong kernel sẽ kiểm tra access vector cache (AVC), là một bộ nhớ chứa những quyết định của SELinux trước đó Nếu một quyết định không thể tạo được cơ sở trên dữ liệu của AVC, yêu cầu sẽ tiếp tục gửi đến security server Nó sẽ tìm kiếm ngữ cảnh bảo mật (security context) của chủ thể và đối tượng trong ma trận Quyền truy cập sau đó sẽ được chấp nhận hoặc từ chối Với AVC, nếu quyền truy cập bị từ chối thì nó sẽ được thông báo trong file /var/log/messages Ngữ cảnh bảo mật của chủ thể và đối tượng được áp dụng từ việc cài đặt chính sách, nó cung cấp thông tin đưa vào ma trận của security server Như hình minh họa dưới đây:
Trang 61.5 Lợi ích của việc sử dụng SeLinux:
- Tất cả các tiến trình và file được gắn nhãn với một kiểu Mỗi kiểu định nghĩa một tên miền cho các tiến trình, và một kiểu cho các file Các tiến trình được tách riêng bằng cách chạy trên các tên miền của của mỗi tiến trình Và các rule của Selinux policy định nghĩa cách các tiến trình tương tác với file, cũng như cách thức các tiến trình tương tác với nhau Truy cập chỉ được cho phép nếu tồn tại một Selinux policy rule mà đặc biệt cho phép nó truy cập
- SELinux có thể được sử dụng để thực thi dữ liệu bảo mật và tính toàn vẹn, cũng như bảo vệ các quá trình từ đầu vào không đáng tin cậy
- Selinux như một thủ tục hành chính, được thi hành trên toàn bộ hệ thống
và không được thiết lập theo ý người dùng
- Giảm bớt thiệt hại bởi các cuộc tấn công đặc quyền gây ra
VD: Khi những tiến trình chạy trong những tên miền, chúng được tách riêng
ra Và các rule của SeLinux policy quy định cách thức những tiến trình truy cập đến file và những tiến trình khác Nếu một tiến trình bị tấn công, những kẻ tấn công chỉ có thể truy cập đến những chức năng bình thường của tiến trình đó, và tới những file đã được cấu hình cho phép truy cập tới
Trang 7II- KIẾN TRÚC BẢO MẬT SELINUX:
2.1 Các ngữ cảnh bảo mật được áp dụng trong SeLinux
Việc kiểm soát truy cập tài nguyên trên các hệ điều hành được dựa vào một vài loại thuộc tính quản lý truy cập kết hợp với các đối tượng (file, socket, network host) và chủ thể (application, process) Tất các các đối tượng và chủ thể này đều có một ngữ cảnh bảo mật riêng kết hợp cùng Một ngữ cảnh bảo mật (security context ) có ba thành phần chính: người dùng (user), vài trò (role) và một mã loại (type Identifier) và có định dạng format như sau:
Các mã kiểu chuỗi nhận dạng giữa các thành phần được định nghĩa trong các phần chính sách (policy) của SELinux (và sẽ được thảo luận kĩ hơn ở phần sau) Bây giờ ta chỉ cần hiểu đơn giản rằng một security context đúng phải có một user, role và mã lọai phù hợp với các yêu cầu về chính sách bảo mật của Selinux
Thông thường để hiện thị các ngữ cảnh bảo mật của các đối tượng và chủ thể trong Selinux, ta thường thêm đuôi –Z vào phần các câu lệnh như:
Ls –Z : hiển thị security context của các đối tượng file hệ thống
Ps –Z : hiển thị security context của các tiến trình trong hệ thống
Id –Z : hiển thị cho user, role và type của user hiện thời
2.2 So sánh giữa Linux chuẩn và SeLinux
Để hiểu rõ hơn về SeLinux, ta sẽ làm một phép so sánh nhỏ của security context với Linux chuẩn Trong Linux chuẩn, các thuộc tính quản lý truy cập của
1 chủ thể chính là user và group ID kết hợp với tất cả tiến trình thông qua cấu trúc tiến trình trong hệ thống Các thuộc tính này được bảo vệ bởi hệ thống và chỉ được thay đổi thông qua các công cụ quản trị như tiến trình login và chương trình setuid.Đối với các đối tượng như file, inode (index node là một khái niệm để lưu thông tin cơ bản như file type, permission, Owner,… của đối tượng) chứa một tập các bit về chế độ truy cập, ID của group và file user Người ta dùng tập kết hợp của 3 bit read/write/excute để quản lý quyền truy cập
system_u:object_r:passwd_exec_t:s0:c0.c2 - s2: c0.c1
user:role:type:sensitivity[:category,…][-sensitivity[:category,…]]
Trang 8Trong SeLinux, các thuộc tính quản lý truy cập luôn luôn gồm 3 phần (user, role, type) Tất cả các đối tượng và chủ thể trong hệ điều hành đều có một ngữ cảnh truy cập kết hợp giữa 3 thành phần này Trong khi bản Linux chuẩn dùng ID của tiến trình dành cho từng user, group; chế độ truy cập của file và các ID cho file để cấp quyền truy cập tài nguyên hay ko, bản SeLinux dùng các ngữ cảnh bảo mật của một tiến trình và các đối tượng để cấp quyền truy cập
Bảng so sánh quyền quản lý truy cập giữa Linux chuẩn và các thuộc tính được thêm vào trong SeLinux:
Bản Linux chuẩn SeLinux thêm vào
Các thuộc tính bảo mật của
tiến trình Các user và group ID
Quyền được xem xét giữa kiểu tiến trình và kiểu file
Trong SeLinux, mọi việc truy cập đều phải được cấp quyền một cách rõ ràng, không có cái niệm cho ―truy cập theo mặc định‖ không quan tâm tới user, group
ID nào Tức là trong SELinux không có khái niệm superuser như root trong Linux chuẩn Việc truy cập được xác định nhờ thông tin của loại chủ thể (subject)
và loại đối tượng được truy cập (object) bằng cách dùng quy tắc allow (cho phép) Một quy tắc allow gồm bốn thành phần:
- Các loại nguồn truy cập (source types): Thông thường là các loại tiến trình truy cập đến tài nguyên
- Loại đích đến (target types): Đối tượng được truy cập như file hoặc thư mục…
- Các loại đối tượng (object classes): Lớp các đối tượng được cho phép truy cập
- Quyền (permissions): Quyền truy cập được phép đối với nguồn truy cập Xét ví dụ sau:
allow user_t bin_t : file {read execute getattr}
Ví dụ trên cho thấy cú pháp cơ bản của 1 loại quy tắc allow Quy tắc này có
2 định danh: đối tượng truy cập: user_t; tài nguyên được truy cập: bin_t file là
Trang 9tên của lớp đối tượng được thiết lập trong các chính sách bảo mật Các quyền được cho phép ở trên đối với đối tượng truy cập là: read, execute và lấy thông tin thuộc tính đối với tài nguyên bin_t Các quyền này được bao lại bằng các dấu ngoặc móc( {, })
Trong SeLinux, quyền hạn (permissions) về căn bản là tổng quan hơn so với bản Linux chuẩn nơi chỉ có bộ ba (rwx) Trong trường hợp trên, quyền read và execute đã thể hiện đầy đủ qua tên, chỉ còn quyền getattr là hơi thiếu rõ ràng Căn bản, quyền getattr chỉ cho phép xem các thuộc tính như ngày tháng, giờ và các chế độ quyền đặc trưng khác
Hình vẽ sau thể hiện cho ví dụ ở trên:
Trang 10III- KIẾN TRÚC NHÂN SELINUX
SELinux cung cấp điều khiển truy cập nâng cao trên tất cả tài nguyên kenel Trong dạng hiện thời của nó, SELinux lồng vào nhân thông qua LSM framework
Một sự phân nhánh của LSM đó là SELinux chỉ được khuyến khích kiểm tra nếu truy cập thành công theo Linux chuẩn Trong thực tế, điều này không ảnh hưởng tiêu cực trên chính sách điều khiển truy cập bởi vì sự điều khiển truy cập SELinux có thể hạn chế hơn chuẩn Linux DAC và không đè lên quyết định của DAC Tuy nhiên, LSM có thể ảnh hưởng đến dữ liệu kiểm soát được tập hợp bởi SELinux Ví dụ, nếu bạn muốn dùng dữ liệu kiểm soát của SELinux để theo dõi
Trang 11tất cả những truy cập bị từ chối, thì trong đa số trường hợp SELinux sẽ không được tham khảo, vì vậy sẽ không thể kiểm soát được, nếu bảo mật Linux chuẩn
từ chối LSM framework bao hàm toàn diện và những hook được rải rác khắp kernel Mỗi LSM hook phân bổ cho một hoặc nhiều quyền truy cập cho một hoặc nhiều lớp đối tượng Và việc tìm hiểu quyền truy cập đối tượng truy cập là phần lớn liên quan đến việc tìm hiểu những LSM hook
3.2 Đơn vị cấu thành SELinux LSM (SELinux LSM module)
Kiến trúc nhân SELinux bao gồm 3 thành phần chính: Security server, object manager, và Access Vector Cache
LSM tạo ra một sự khác biệt lớn giữa các chính sách bảo mật đưa ra quyết định và chính sách thực thi các chức năng Đưa ra những quyết định chính sách là việc của security server Tên security server phản ảnh gốc microkernel của SELinux, nơi mà vai trò quyết định chính sách được gói gọn trong userspace server
Trong Linux, security server cho đối tượng kernel được đặt trong module SELinux LSM Policy dùng cho security server được biểu hiện trong những quy định được nạp thông qua giao diện quản lý policy Những quy định này có thể khác nhau tùy theo hệ thống, làm sao cho SELinux có thể thích ứng cao với từng mục đích bảo mật của các tổ chức khác nhau
Object managers chịu trách nhiệm thi hành những quy định policy của security server cho những tài nguyên mà chúng quản lý
Thành phần thứ ba của cấu trúc SELinux là access vector cache (AVC) AVC là nơi lưu trữ những quyết định truy cập được tạo bởi security server cho
Trang 12việc kiểm tra truy cập kế tiếp và như vậy cung cấp những cải tiến quan trọng cho việc phê chuẩn truy cập AVC còn cung cấp những giao tiếp SELinux cho LSM hook và từ đó quản lý những đối tượng kernel AVC được dỡ bỏ khi một policy được nạp vào, qua đó giữ bộ đệm được nhất quán
Tuy nhiên, SELinux không hoàn toàn thực hiện hủy bỏ truy nhập trên policy Trong chuẩn Linux, nếu bạn có một tập tin mô tả, bạn có thể sử dụng nó bất chấp
sự thay đổi trong chế độ truy file
3.3 Userspace Object Managers
Một trong những tính năng mạnh mẽ của kiến trúc SELinux là nó có thể được áp dụng cho tài nguyên của userspace và tài nguyên của kernel Ví dụ về các máy chủ userspace trong Linux có thể được tăng cường để thực thi kiểm soát truy cập trên các tài nguyên của chúng bao gồm máy chủ X và các dịch vụ cơ sở
dữ liệu Mỗi máy chủ cung cấp các nguồn tài nguyên trừu tượng (windows, tables ) qua đó bảo mật bắt buộc có thể được cung cấp Hãy xem xét hai cách
mà các kiến trúc SELinux hỗ trợ máy chủ userspace
3.3.1 Những hỗ trợ của kernel cho Userspace Object Manager
SELinux hỗ trợ các đối tượng userspace trực tiếp thông qua các máy chủ đã được cấu hình bảo mật trong nhân, như mô tả trong hình:
Trang 13Trong phương pháp này, userspace object manager hoạt động giống như các kernel object managers Các máy chủ an ninh kernel chứa đựng tất cả các chính sách bảo mật tổng thể, và userspace object manager phải truy vấn kernel cho các quyết định kiểm soát truy cập Sự khác biệt chính là userspace object manager không thể sử dụng AVC của kernel mà mỗi máy chủ phải có AVC riêng biệt chứa các quyết định đã được yêu cầu từ kernel Chức năng AVC cho userspace object manager có trong thư viện libselinux
Sự khác biệt nữa là userspace object manager không có các hook LSM Thay vào đó, userspace object manager có giao tiếp nội bộ với AVC của nó bên trong libselinux AVC xử lý việc không tìm thấy cache và truy vấn đến kernel thay cho object manager
Tuy đơn giản, phương pháp để hỗ trợ quản lý đối tượng userspace này có một số điểm yếu Trước tiên, để sử dụng kiểu ép buộc (type enforcement), Object manager phải xác định các lớp đối tượng đó đại diện cho các nguồn tài nguyên nào Ví dụ, một máy chủ cơ sở dữ liệu có thể định nghĩa các lớp đối tượng đó bao gồm: cơ sở dữ liệu, bảng, sơ đồ, entry, Đối với nguồn tài nguyên kernel, các lớp đối tượng được cố định và tương ứng với những offset lớp hard-coded được định nghĩa trong tiều đề file của module SELinux LSM Hai máy chủ userspace phải cẩn thận để không sử dụng cùng một lớp đối tượng trong kernel Kernel không có cách nào để quản lý xung đột này
Điểm yếu thứ hai là kernel security server (máy chủ đã được cấu hình bảo mật trong nhân) đang quản lý chính sách đối với lớp đối tượng cho các object manager không nằm trong kernel Điều này làm tăng chi phí lưu trữ trong kernel cho những thứ không liên quan đến kernel, và có thể tác động đến chi phí xác nhận policy cho AVC
3.3.2 Kiến trúc Policy Server
Để tìm hiểu các điểm yếu của việc sử dụng máy chủ bảo mật trong kernel cho userspace object manager và để tăng cường khả năng bảo mật của SELinux,
là một nỗ lực liên tục để xây dựng userspace hỗ trợ cho các các userspace object manager Dự án này có hai mục tiêu chính như sau:
- Cung cấp hỗ trợ tốt hơn cho người user-space object manager bằng cách cung cấp một user-space security server ra quyết định truy cập cho từng thành phần user của policy
- Cung cấp phân định mức kiểm soát truy cập tinh tế (fine-grained access control) cho các chính sách riêng của mình bằng cách xây dựng một máy chủ quản lý chính sách (policy management server) đó là một userspace object manager mà các lớp đối tượng đại diện cho từng thành phần của policy
Trang 14Hình : Userspace object managers sử sụng kernel security server
Trong các kiến trúc policy server, tất cả các thao tác và quản lý của hệ thống chính sách tổng thể được điều khiển thông qua các máy chủ quản lý chính sách (policy management server - PMS) PMS bản thân là một userspace object manager ở chỗ nó tạo ra các lớp đại diện cho các đối tượng chính sách và thi hành một phần định mức kiểm soát truy cập tinh tế trên tài nguyên Tính năng này cung cấp riêng cho việc tăng cường bảo mật quan trọng cho SELinux Với PMS, ta có thể cho phép truy cập vào các phần của các chính sách và giới hạn truy cập cho người khác Ví dụ, các SELinux policy có thể cho phép người sử dụng công cụ quản lý để thêm người sử dụng và thực hiện gán các role, nhưng không được thay đổi kiểu cho phép thực thi các quy tắc (rule) Tốt hơn, ta có thể
ủy quyền cho một máy chủ cơ sở dữ liệu để thay đổi thực thi kiểu (TE) quy định liên quan đến các lớp đối tượng và kiểu của nó, nhưng không những của hạt nhân
Chức năng chính thứ hai của PMS là để chia nhỏ các chính sách hệ thống vào trong nhân và người sử dụng, rồi load chúng tương ứng vào máy chủ đã được cấu hình bảo mật trong nhân (kernel security server) và máy chủ đã cấu hình bảo mật trong userspace (userspace sercurity server-USSS) Bằng cách này, hạt nhân không nhận biết được các quy tắc và các lớp đối tượng chỉ liên quan đến userspace object manager Userspace object manager truy vấn USSS và không
