Tiểu luận: SECURITY ENHANCED LINUX

Chia sẻ: Hoang Thuy | Ngày: | Loại File: PDF | Số trang:28

Thêm vào BST

Báo xấu

280
lượt xem 89
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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......

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Tiểu luận: SECURITY ENHANCED LINUX

HỌ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 Tên đồ án: SECURITY ENHANCED LINUX (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 Lớp : Đ06THA1 TP Hồ Chí Minh-11/2009
I- 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 1
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ì 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 2
trì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. 3
Trong 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: 4
1.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. 5
II- 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: system_u:object_r:passwd_exec_t:s0:c0.c2 - s2: c0.c1 user:role:type:sensitivity[:category,…][-sensitivity[:category,…]] 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. 6
Trong 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 Các user và group ID Ngữ cảnh bảo mật tiến trình Các thuộc tính bảo mật cho đối Chế độ truy cập và các Ngữ cảnh bảo mật tƣợng ID của user và group trên file Các điểm căn bản cho quản lý Việc xử lý các ID của Quyền đƣợc xem truy cập user/group và chế độ xét giữa kiểu tiến truy cập dựa vào ID của trình và kiểu file user/group trên 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à 7
tê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: 8
III- 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. 3.1 LSM Framework. Ý tƣởng phía sau LSM là cho phép những modules security tích hợp vào trong nhân để có thể tăng cƣờng bảo mật cho cơ chế DAC. LSM cung cấp một bộ các móc (hook). Những hook này thƣờng đƣợc đặt sau khi truy cập theo tiêu chuẩn Linux đã kiểm tra, nhƣng trƣớc khi tài nguyên thực sự đƣợc truy cập bở i kernel với tƣ cách là ngƣời gọi. 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 9
tấ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 10
việ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: 11
Trong 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. 12
Hì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 13
phải hạt nhân. Các AVC trong các userspace object manager khác nhau đăng ký với USSS để cập nhật các chính sách và các chức năng liên la ̣c cache . Kiến trúc máy chủ chính sách có một số điểm mạnh, từ thêm vào cho đến loại bỏ các trách nhiệm của kernel cho các nguồn tài nguyên userspace và phân định mức truy cập tinh tế để quản lý chính sách. Chúng ta có thể mở rộng giao tiếp của PMS cho phép truy cập mạng từ xa để quản lý chính sách phân tán. Các PMS và USSS đƣợc thiết kế để cho phép đăng ký thời gian thực của các lớp đối tƣợng, phá vỡ những phụ thuộc cho userspace object manager tồn tại trong hạt nhân. Sự khác biệt giữa hai phƣơng pháp tiếp cận đƣợc che giấu bởi libselinux cung cấp tƣơng thích với công việc hiện tại. Cuối cùng, PM S và USSS đƣợc thiết kế nhƣ các dịch vụ riêng biệt để cho phép một hoặc cả hai sẽ đƣợc sử dụng mà không có sự khác biệt. Ví dụ, trong một hệ thống nơi đƣợc phân định tinh tế chính sách truy cập là không cần thiết, các USSS có thể đƣợc sử dụng một mình để hỗ trợ các userspace object server khác. 14
IV- MỘT SỐ MÔ HÌNH ACCESS CONTROL: 4.1 Access control matrix. 4.1.1 Access control list selinux (ACLs) * Access control list (ACLs) là gì ? Access control list là danh sách điều khiển truy cập định danh các quyền và phép đƣợc chỉ định cho một chủ thể (subject) hoặc một đối tƣợng (object). * Tại sao phải sử dụng Access control list (ACLs)? Ta sử dụng Access control list là vì nó đƣa ra một 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. * Các thuận lợi của Access control list (ACLs) Thông thƣờng trong Linux có 3 quyền: read, write, execute tƣơng ứng (r,w,x) với 3 nhóm ngƣời dùng: owner, group, other. Các bit này đƣợc sử dụng để xác định đặc tính cho tất cả các hệ thống trong Linux. Thêm vào đó, SUID, SGID, sticky bit có thể đƣợc dùng trong các trƣờng hợp đặc biệt. ACLs đƣợc sử dụng trong trƣờng hợp mà các khái niệ m permission của file thông thƣờng không có hiệu lực. Chúng cho phép gán quyền cho một ngƣời, hoặc một nhóm cá nhân thậm chí không tƣơ ng ứng với owner hoặc owning group. ACLs hỗ trợ các hệ thống file ReiserFS, Ext2, Ext3, JFS, XFS. Bạn có thể thấy rõ thuận lợi của ACLs khi thay thế 1 server chạy Windows bằng 1 server chạy Linux. Một số trạm kết nối vẫn có thể chạy trên Windows ngay cả sau khi chuyển đổi. Hệ thống Linux sẽ chuyển các file và dịch vụ về clients chạy windows với Samba (dịch vụ chia sẻ) Samba cũng hỗ trợ ACLs và lúc đó quyền của ngƣời dùng có thể đƣợc cấu hình trên cả Linux và Windows bằng GUI. winbindd còn có khả năng gán quyền cho user chỉ tồn tại trên Windows domain mà ko có account nào trên Linux server. M ặt khác bạn có thể chỉnh sửa ACLs với getfacl và setfacl. * Hoạt động của Access control matrix gồm (ACLs) và Capabilities (C-list). Chúng ta sẽ xác định một subject nhƣ là một ngƣời sử dụng của một của một hệ thống (không nhất thiết phải một ngƣời sử dụng nhân lực) và một object nhƣ là một nguồn tài nguyên hệ thống. Hai khái niệm cơ bản trong các lĩnh vực đƣợc phép truy cập là kiểm soát danh sách (ACLs), và capabilities(C-list).Cả hai ACL và C-list có nguồn gốc từ Lampson’s access control matrix, đối với hàng cho nhiều subject và cột cho nhiều object. Các truy cập đƣợc cho phép theo chủ đề (S) để đối tƣợng (O) đƣợc lƣu trữ tại các giao điểm giữa hàng subject và cột object. Ví dụ : về một điều khiển truy cập (ta sử dụng 3 quyền là x,r,w) TABLE 8.1. Access control matrix. 15
Accounting Accounting Insurance Payroll OS Program Data Data Data — — Bob rx rx r Alice rx rx r rw rw Sam rwx rwx r rw rw acct. program rx rx rw rw r Trong bảng trên ta xem chƣơng trình kế toán(Accounting program) đƣợc xem nhƣ là một subject và cả object, bằng cách này chúng ta có thể thi hành các hạn chế rằng các dữ liệu kế toán(Accounting data) có thể chỉ đƣợc sửa đổi theo các chƣơng trình kế toán.Làm nhƣ vậy thì dữ liệu kế toan sẽ khó bị sửa(tức là thay đổi dữ liệu) Vì bất kỳ thay đổi cho kế toán dữ liệu phải đƣợc thực hiện bởi phần mềm và phần mềm đó phải bao gồm các tiêu chuẩn kế toán và kiểm tra số dƣ tài khoản. Tuy nhiên, điều này không ngăn chặn tất cả các cuộc tấn công. Vì nhà quản trị hệ thống nhƣ Sam có thể thay thế các chƣơng trình kế toán bằng các sửa đổi (hoặc chƣơng trình gian lận nào đó). Nhƣng điều này cho phép lừa Alice và Bob truy cập vào dữ liệu kế toán mà không cho phép họ sửa đổi (cố ý hay không cố ý). Vì tất cả các subject và object xuất hiện trong ma trận kiểm soát truy cập, nó chứa tất cả các thông tin có liên quan mà trên đó cho phép đƣa vào đó để quyết định. Tuy nhiên, có một vấn đề thực tiễn trong việc quản lý một ma trận điề u khiển truy cập lớn. Thực ra một hệ thống có thể có hàng trăm subject và hàng chục ngàn object trong trƣờng hợp đó một ma trận kiểm soát truy cập với hàng triệu mục sẽ cần phải đƣợc tham khảo trƣớc khi chia nhỏ ra từng subject và object. Ta có thể chia thành các ma trận cột và mỗi khối lƣu trữ cột với đố i tƣợng tƣơng ứng của nó. Khi đó bất cứ khi nào một đối tƣợng đƣợc truy cập, cột của ma trận kiể m soát truy cập có thể đƣợc cho phép để xem liệu đƣợc phép hoạt động. Các cột này đƣợc gọi là danh sách kiểm soát truy cập(ACL). Ví dụ hình 8.1: ACL tƣơng ứng với Insurance data trong bảng 8.1 (Bob, —), (Alice, rw), (Sam, rw), (Accounting program, rw) Ngoài ra, chúng tôi có thể lƣu trữ ma trận kiểm soát truy cập bằng hàng, trong đó mỗi dòng đƣợc lƣu trữ với subject tƣơng ứng của nó.Các hàng này đƣợc xem là Capabilities (C-list). Ví dụ hình 8.1: Alice của C-list trong Bảng 8.1 là (OS, rx), (accounting program, rx), (accounting data, r), (insurance data, rw), (payroll data, rw). 16
Ta thấy có vẻ nhƣ ACL và C-list là tƣơng đƣơng nhau, vì đơn giản là cung cấp các cách khác nhau c ủa lƣu trữ các thông tin có liên quan. Tuy nhiên, có một số khác biệt giữa hai phƣơng pháp tiếp cận. Ví d ụ So sánh giữa ACLs và (C-list) trong hình trên. Lƣu ý là các mũi tên trong hình trên.Với ACLs thì điểm mũi tên từ các nguồn tài nguyên (resources) đến ngƣời sử dụng (user), trong khi đó đối với C- list thì điểm mũi tên từ những ngƣời sử dụng các nguồn tài nguyên. Sự khác biệt này thật quan trọng và ý nghĩa. Đặc biệt, với C-list sự liên kết giữa các user và các tập tin đƣợc xây dựng trong hệ thống, còn đối với ACLs dựa trên hệ thống một phƣơng pháp riêng biệt cho kết hợp ngƣời sử dụng các tập tin đƣợc yêu cầu. Điều này minh họa là C-list có khả năng bảo mật thuận lợi hơn ACLs, với lý do này nên C-list đƣợc sử dụng nhiều. 4.2 Multilevel Security Models Trong phần này chúng ta sẽ thảo luận về mô hình an ninh trong phần security multilevel. Ở đây, chúng ta sẽ chỉ đề cập đến hai trong số các mô hình tốt nhất đƣợc biết đến và chúng ta chỉ trình bày một tổng quan về hai mô hình. Mục đích một giới thiệu kỹ hơn về MLS và các mô hình an ninh có liên quan. Về MLS các subject là những ngƣời sử dụng và các object là các dữ liệ u đƣợc bảo hộ (tài liệu). Phân loại ứng dụng cho các object khi sử dụng thông tin 17
bí mật ứng dụng cho các subject. Bộ Quốc phòng M ỹ sử dụng 4 mức độ bảo mật TOP Secret > Secret > Confidential > Unclassified nhƣ hình minh họa. Với một subject ví dụ thông tin bí mật Secret đƣợc phép truy cập vào các đối tƣợng đƣợc phân loại Secret hoặc thấp hơn nhƣng không phép truy cập đến phân loại đối tƣợng TOP Secret. Một số điểm cần lưu ý về MLS: - Bảo mật dùng kỹ thuật MLS kết hợp giữa các mức bảo mật nhạy cảm có thứ bậc( Confidential, Secret, TopSecret) và một tập các lọai không thứ bậc(US Only, Army,…) và thƣờng đƣợc dùng trong các hệ thống của quân đội và chính phủ vì phản ánh đúng các chính sách tồn tại trong thực tế. Một Security Leve l phải có 1 cấp độ bảo mật nhạy cảm( Sensitivity) kết hợp với không hoặc nhiề u loại. Ví dụ: {Secret/UFO, Crypto}, {Top Secret/UFO, Crypto, Stargate } và { Unclassified } - User đƣợc cấp quyền truy cập thông tin cấp độ thấp (Confidential) không thể có quyền truy cập dữ liệu có cấp độ cao hơn (Secret). Các tiến trình có mức bảo mật nhạy cả m ở cấp độ cao nhƣ Secret có thể đọc, ghi vào các đối tƣợng cùng cấp (Secret) nhƣng chỉ có khả năng đọc đối với đối tƣợng UnClassified. Ví dụ: đối với các hệ điều hành đa nền cho phép dữ liệu thuộc cấp TopSecret và Unclassified cùng đƣợc lƣu trữ chung trong hệ thống song không cho phép d ữ 18
liệu TopSecret đƣợc đặt trong môi trƣờng hoặc user cấp Unclassified. Hình minh họa: Bây giờ ta xem xét hai mô hình Bell-LaPadula và Biba. ● Bell-LaPadula: Các mô hình bảo mật đầu tiên mà chúng tôi sẽ xem xét là Bell- LaPadula (BLP) ta xem xét và tin tƣởng hay không.mô hình BLP đƣợc đặc tên theo hai nhà phát minh Elliot Bell và Len LaPadula. Mục đích của BLP là nắm bắt đƣợc các yêu cầu tối thiểu đối với bảo mật mà bất kỳ Multilevel Security Models ( MLS ) hệ thống phải đáp ứng. BLP bao gồm hai câu sau đây: - Simple Security Condition : subject S có thể đọc object O khi và chỉ khi L (O) ≤ L (S) - Property (Star Property) : subject S có thể viết object O khi và chỉ khi L (S) ≤ L (O) Chú ý: trong đó Mức độ bảo mật của O là kí hiệu L(O), và mức độ bảo mật của S là ký hiệu là L (S) ● Biba’s Model: Trong phần này, chúng ta sẽ xem ngắn gọn về mô hình của Biba. Trong khi BLP đề cập đến sự cẩn mật,còn mô hình Biba với toàn vẹn.Trong thực tế, Biba của mô hình cơ bản là một tính toàn vẹn phiên bản của BLP.Nếu chúng ta tin tƣởng vào tính toàn vẹn của đối tƣợng O1 nhƣng không tin tƣởng vào đối tƣợng O2.khi đó nếu đối tƣợng O bao gồm cả O1 và O2 thì chúng ta không thể tin 19