Đồ án Security enhanced linux (selinux)

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: 5 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. 6 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: 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,…]] 7 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 tiến trình Các user và group ID Ngữ cảnh bảo mật Các thuộc tính bảo mật cho đối tƣợng Chế độ truy cập và các ID của user và group trên file Ngữ cảnh bảo mật Các điểm căn bản cho quản lý truy cập Việc xử lý các ID của user/group và chế độ truy cập dựa vào ID của user/group trên file đó. 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à 8 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: 9 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 10 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 11 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: 12 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. 13 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 14 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 lac̣ 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, PMS 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. 15 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. 16 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). 17 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 18 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 Level 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ữ 19 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 S