Báo cáo bài tập lớn môn An toàn hệ điều hành

19 264 0
Báo cáo bài tập lớn môn An toàn hệ điều hành

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

Xây dựng các tình huống của hệ thống file •Tuân thủ và vi phạm các yêu cầu của hệ thống file •Kiểm tra các tình huống này bằng Alloy Xây dựng mô hình an toàn Bell-La Padula và Biba •Xây dựng các chính sách an toàn minh họa cho các mô hình này •Đánh giá các chính sách này với yêu cầu an toàn của mô hình

HỌC VIỆN CƠNG NGHỆ BƯU CHÍNH VIỄN THƠNG - - BÁO CÁO BÀI TẬP LỚN MÔN: AN TỒN HỆ ĐIỀU HÀNH Giảng viên : Phạm Hồng Duy Bài tập lớn mơn An tồn hệ điều hành Nhóm Đề bài: Xây dựng tình hệ thống file  Tuân thủ vi phạm yêu cầu hệ thống file  Kiểm tra tình Alloy Xây dựng mơ hình an tồn Bell-La Padula Biba  Xây dựng sách an tồn minh họa cho mơ hình  Đánh giá sách với yêu cầu an tồn mơ hình I Xây dựng tình hệ thống file • Tuân thủ vi phạm yêu cầu hệ thống file • Kiểm tra tình Alloy Tuân thủ vi phạm yêu cầu hệ thống file: a) Các tình tuân thủ yêu cầu hệ thống file - Đường dẫn hệ thống file không tuần hồn Trong hệ thống file, khơng có thư mục chứa nghĩa quan hệ thư mục khơng quay vòng Để kiểm tra thuộc tính hệ thống cần xây dựng khai báo assert dùng lệnh check để yêu cầu Alloy kiểm tra phản ví dụ cho mệnh đề khẳng định Khai báo fact bắt buộc mệnh đề phải assert cho số thứ phải hành vi mơ hình Như quan hệ thể tập đóng bắc cầu khai báo thơng qua tốn tử: assert acylic { no d: Dir \ in d.^contents // khơng có thư mục chứa } Để kiểm tra mơ hình với tối đa đối tượng FSObject sử dụng câu lệnh sau: check acyclic for // kiểm tra mơ hình với tối đa đối tượng object - Khi kiểm tra, Alloy xem xét trường hợp mà mức cao đối tượng có tối đa Có thể có hai kết quả:  “no solution found” nghĩa khơng có phản ví dụ câu khẳng định mơ hình với phạm vi kiểm tra thời  “solution found” nghĩa có phản ví dụ Ví dụ biểu diễn dạng đồ họa Mỗi File System Object(FSObject) nằm nhiều Directory  Mỗi file tệp tin hệ điều hành nằm thư mục  Hệ thống file có số ràng buộc để chắn đối tượng hoạt động theo cách người dùng kỳ vọng Ví dụ quan hệ cấp (parent) nội dung (content) cần không mang quan hệ với Ngồi ra, có quan hệ ràng buộc tường minh thư mục cấp với đối tượng chứa bên  Hay với thư mục d o thuộc nội dung contents d cấp o d Nếu khơng có ràng buộc có tình huống, File có cấp thư mục gốc Root hay thư mục có cấp  Phát biểu fact thể ràng buộc tường minh mơ hình Alloy tìm kiếm ví dụ (trạng thái hệ thống thỏa mãn ràng buộc) ví dụ vi phạm ràng buộc bị loại bỏ Nếu ràng buộc bị lỗi khơng thể tìm thấy ví dụ  Khi khai báo Dir File thừa kế FSObject nghĩa khơng có đối tượng FSObject vừa File vừa thư mục Dir Nhưng cần có ràng buộc khơng có FSObject khơng thuộc hai loại đối tượng  Để kiểm tra tính đắn tình ta dùng câu lệnh: assert oneLocation { all o: FSObject | lone d: Dir | o in d.contents } check oneLocation for b) Các tình vi phạm yêu cầu hệ thống file - Khơng có file root hệ thống file Hệ thống file có thư mục gốc Root tập đối tượng hệ thống file tập đối tượng truy nhập từ thư mục gốc Root Chúng ta kiểm tra câu lệnh bên đây: assert noRoot { no d: Dir | no d.parent // tất directory parent } check noRoot for - Hai File System Object(FSObject) ( khơng phải root) có chung parent Chúng ta xét mơ hình hệ thống file đơn giản sau đây: FileSystem = {(FS0)} FSObject = {(F0), (F1), (F2), (F4), (D0), (D1)} File = {(F0), (F1), (F2), (F4)} Dir = {(D0), (D1)} Parent = {(FS0,F0,D0),(FS0,D1,D0),(FS0,F1,D1),(FS0,F2,D1)} Dễ thấy tình hồn tồn khơng xác, FSObject có riêng cho parent Ta dùng ngơn ngữ alloy để kiểm tra lại: assert sameParent { all obj, p: (FSObject - Root) | (obj.parent = p.parent) } check sameParent for Kiểm tra tình Alloy: - Hệ thống file (File System) Ta kiểm tra mơ hình cách tìm kiếm phản ví dụ Ở đây, Alloy kiểm tra tất hệ thống file với tối đa đối tượng FSObject, cố gắng tìm hệ thống vi phạm khẳng định thời Khi kiểm tra thực thi, có kết quả:  no solution found nghĩa khơng có phản ví dụ câu khẳng định  solution found nghĩa có phản ví dụ câu khẳng định a) Các tình tuân thủ hệ thống file: - Đường dẫn hệ thống file tuần hoàn: sig FSObject { parent: lone Dir } sig Dir extends FSObject { contents: set FSObject } sig File extends FSObject { } fact { all d: Dir, o: d.contents | o.parent = d } fact { File + Dir = FSObject } one sig Root extends Dir { } { no parent } fact { FSObject in Root.*contents } assert acyclic { no d: Dir | d in d.^contents } check acyclic for - Hệ thống file có thư mục gốc: sig FSObject { parent: lone Dir } sig Dir extends FSObject { contents: set FSObject } sig File extends FSObject { } fact { all d: Dir, o: d.contents | o.parent = d } fact { File + Dir = FSObject } one sig Root extends Dir { } { no parent } fact { FSObject in Root.*contents } assert oneRoot { one d: Dir | no d.parent } check oneRoot for - Mỗi đối tượng có chỗ hệ thống file: sig FSObject { parent: lone Dir } sig Dir extends FSObject { contents: set FSObject } sig File extends FSObject { } fact { all d: Dir, o: d.contents | o.parent = d } fact { File + Dir = FSObject } one sig Root extends Dir { } { no parent } fact { FSObject in Root.*contents } assert oneLocation { all o: FSObject | lone d: Dir | o in d.contents } check oneLocation for  Ta nhận kết “No counterexample found Assertion may be valid.”, điều có nghĩa khơng có vấn đề tìm thấy kiểm tra b) Các tình vi phạm hệ thống file: - Hai đối tượng (không phải Root) có chung parent: sig FSObject { parent: lone Dir } sig Dir extends FSObject { contents: set FSObject } sig File extends FSObject { } fact { all d: Dir, o: d.contents | o.parent = d } fact { File + Dir = FSObject } one sig Root extends Dir { } { no parent } fact { FSObject in Root.*contents } assert sameParent{ all o, p: (FSObject - Root) | (o.parent = p.parent) } check sameParent for  Tìm counterexample assert thời: - Hệ thống file không tồn thư mục gốc Root: sig FSObject { parent: lone Dir } sig Dir extends FSObject { contents: set FSObject } sig File extends FSObject { } fact { all d: Dir, o: d.contents | o.parent = d } fact { File + Dir = FSObject } one sig Root extends Dir { } { no parent } fact { FSObject in Root.*contents } assert noRoot{ no d: Dir | no d.parent } check noRoot for  Tìm counterexample assert thời: - Đối tượng có nhiều chỗ hệ thống file: sig FSObject { parent: lone Dir } sig Dir extends FSObject { contents: set FSObject } sig File extends FSObject { } fact { all d: Dir, o: d.contents | o.parent = d } fact { File + Dir = FSObject } one sig Root extends Dir { } { no parent } fact { FSObject in Root.*contents } assert manyLocation{ all o: FSObject | some d: Dir | o in d.contents } check manyLocation for  Tìm counterexample assert thời: II Xâ y dựng mơ hình an tồn Bell-La Padula Biba Mơ hình Bell-La Padula Giới thiệu Mơ hình Bell-La Padula mơ hình an tồn bảo mật phổ biến lĩnh vực liên quan đến an ninh quốc phòng, hình thức hóa mơ hình bảo mật đa cấp MAC Mơ hình trọng đến bảo vệ tính bí mật việc kiểm soát truy nhập hệ thống Các đặc trưng mơ hình diễn giải sau:  Quyền truy nhập định nghĩa thông qua ma trận truy nhập mức độ bảo mật đối tượng chủ thể  Các sách an tồn ngăn ngừa thơng tin rò rỉ từ mức bảo mật cao xuống mức thấp  Mơ hình xem xét luồng thơng tin xảy có thay đổi hay quan sát đối tượng Mơ tả mơ hình Để thực việc kiểm sốt truy nhập mơ hình định nghĩa mức dộ an toàn cho đối tượng liệu chủ thể Các mức độ bảo mật sử dụng tối mật (Top Secret – TS), mật (Secret–S), nội (Confidential–C) Còn lại (Unclassified–UC) Trong hệ thống có hiệu ứng tác động chủ thể truy xuất lên thông tin đối tượng là: “obseving” có nghĩa đọc thơng tin đối tượng “alerting” ghi thông tin vào đối tượng Tương ứng với loại hiệu ứng ta có quyền truy xuất thơng tin là:  e – execute (no observation and no alteration)  r – read (observation, but no alteration)  a – append (alteration, but no observation)  w – write (both observation and alteration) Bây sẻ bắt đầu mô tả máy trạng thái mơ hình Trước tiên ta sẻ có số ký hiệu thể thông tin sǀS chủ thể tập chủ thể, oǀO đối tượng tập đối tượng, aǀA={e,r,a,w} tập quyền truy xuất Một trạng thái định nghĩa ba (b,M,F)  b=(s,o,a) current access set Bộ giá trị thể đối tượng s sẻ thực truy xuất a lên đối tượng o  M access permission Là ma trân truy xuất có giá trị phần từ M ij lưu lại quyền truy xuất mà chủ thể Si tác động lên đối tương Oj  f=(fs ,fc ,fo) level function Là ba thể mức độ bảo mật chủ thể đối tượng trạng thái tai Trong f s mức bảo mật cao chủ thể s, fo mức bảo mật đối tượng o cuối f c mức độ bảo mật chủ thể s Chính sách Bộ sách Bell-La Padula có luật phát biểu đơn giản Luật thứ gọi Simple Security Property, ký hiệu ss-property, luật thứ * Property, ký hiệu *-property luật phát biểu chi tiết sau  ss-property: Thuộc tính thỏa mãn với truy xuất b (s,o,a) mà truy xuất a có thuộc tính observe mức độ bảo mật cùa s phải lớn mức độ bào mật o Hay nói rõ (b,M,f) thỏa mã tính chất ss-property b(s,o,a=read/write) fo ≤ fs Xét biểu đồ luồng thông tin ta thấy S2 theo cách gián tiếp đọc liệu từ đối tượng O1 hay nói luồng liệu từ mức cao rò rỉ xuống mức thấp Để tránh tình trạng ta sẻ có thính chất thứ  *-property: Thuộc tính thỏa mãn với tràng thái chủ thể s thực truy xuất observe tới đối tương o1 thực truy xuất alert tới o2 mức độ bảo mật o1 phải lớn mức độ bảo mật o2 Rõ ràng tính chất khơng cho phép trường hợp xảy Cũng theo tính chất phân chia cấp độ đối tượng truy xuất từ chủ thể định Chúng ta định nghĩa lại luật thứ theo current-level sau: Trạng thái (b,M,f) thỏa mãn tính chất với truy xuất b(s,o,a) có a=append fo < fc, a=write fo = fc, a=read fo > fc Có điểm đáng ý thuộc tính thứ khơng áp dụng cho chủ thể tin cậy: Chủ thể tin cậy chủ thể đảm bảo khơng vi phậm sách Ưu nhược điểm Ưu điểm:  Là chế có tính bảo mật cao, thịch hợp mơi trường qn đội phủ Nhược điểm:  Mơ hình tập trung vào tính bảo mất, khơng đảm bảo tính tồn vẹn thơng tin  Khơng linh động việc thay đổi quyền truy cập  Mơ hình khơng chặn convert chanel nghĩa chủ thể mức bảo mật thấp phát diện đối tượng mức bảo mật cao chủ thể thực true xuất đến đối tượng mà bị từ chối  Không hỗ trợ tính đa thể  Quá chặt chẽ nên khó áp dụng mơ hình đời sống Ví dụ: Trong cơng ty có thành phần sau: ban giám đốc, trưởng phòng, nhân vên khác tương ứng với lọai tài liệu, tài liệu hợp đồng công ty, tài liệu nhân sự, tài liệu công việc Công việc cho tài liêu mức cao không tuồn xuống nhân viên cấp thấp Áp dụng mơ hình ta có: Ban giám đốc có quyền đọc khơng thể tuần tài liệu cấp cao xuống mức Các truỏng phòng có quyền đọc thay đổi tài liệu nhân tài liệu cơng việc, biết tồn hợp đồng góp ý Còn nhân viên biết tồn tài liệu góp ý khơng đọc thay đổi nội dung ngồi tài liệu cơng việc 1 Mơ hình tồn vẹn Biba Năm 1977, Biba đề xuất mơ hình (sau gọi mơ hình Biba) xử lý tính toàn vẹn hệ thống chủ thể thực truy xuất đối tượng sử dụng mơ hình máy bảo mật tương tự mơ hình BLP Integrity (Tính tồn vẹn) Tính tồn vẹn đề cập đến tin cậy liệu hay tài ngun Tính tồn vẹn thường xác định điều khoản ngăn chặn thay đổi khơng phù hợp liệu Có ba mục tiêu tính tính tồn vẹn:  Ngăn chặn người sử dụng trái phép sửa đổi liệu hay chương trình  Ngăn chặn người dùng ủy quyền sửa đổi không phù hợp hay trái phép  Duy trì tính thống nội bên ngồi liệu chương trình Set Categories (Thiết lập danh mục) Tập loại chứa nhãn tập hợp tất hệ thống Việc phân loại tập hợp loại không theo thức bậc Ví dụ Set Categories Một ví dụ hai loại loại X = (Detroit, Chicago, New York thể loại) Y = (Detroit, Chicago) Trong trường hợp X ≥ Y (X dominates Y), Y tập hợp X Nếu có loại Z (Detroit, Chicago, Miami) Z X trường hợp khơng thể so sánh yếu tố thứ ba khác Integrity Levels (Cấp độ toàn vẹn) Mỗi cấp độ toàn vẹn đại diện L (C, S), đó:  L mức tồn vẹn  C phân loại  S danh mục Các mức toàn vẹn sau hình thành mối quan hệ thống trị Mức toàn vẹn L ₁ = (C₁, S₁) trội (≥) mức toàn vẹn L₂ = (C ₂, S₂) nếu: C ₁ ≥ C ₂ and S ₁ ⊇ S₂ Chủ thể đối tượng Cũng giống mơ hình khác, mơ hình Biba hỗ trợ kiểm soát truy cập chủ thể đối tượng  Subjects (chủ thể) yếu tố hoạt động hệ thống truy cập thơng tin  Objects (đối tượng) yếu tố thụ động mà truy nhập yêu cầu (files, programs, etc.) Mỗi chủ thể đối tượng mô hình Biba có mức độ tồn vẹn gắn với Access Modes (Chế độ truy cập) Mơ hình Biba bao gồm phương thức truy cập sau:     Modify (Sửa đổi): Cho phép chủ thể ghi đối tượng Observe (Quan sát): Cho phép chủ thể đọc đối tượng Invoke (Triệu gọi): Cho phép chủ thể giao tiếp với chủ thể khác Execute (Thực hiện): Cho phép chủ thể thực đối tượng Biba Policies (Chính sách mơ hình) Mơ hình Biba thực nhóm sách khác sử dụng Mơ hình hỗ trợ sách bắt buộc sách tùy ý (mandatory and discretionary policies) The Mandatory Policies (Chính sách bắt buộc):  Strict Integrity Policy (Chính sách tồn vẹn nghiêm ngặt)  Low-Watermark Policy for Subjects: Chính sách giảm mức tồn vẹn xuống mức chủ thể đọc xuống dựa theo đối tượng quan sát  Low-Watermark Policy for Objects: Giảm mức đối tượng xuống với chủ thể ghi  Low-Watermark Integrity Audit Policy: Bất kỳ chủ thể sửa đối tượng nào, mức toàn vẹn  Ring Policy: Bất kỳ chủ thể quan sát đối tượng nào, mức độ tồn vẹn The Discretionary Policies (Chính sách tùy ý): Access Control Lists (Truy cập vào danh sách điều khiển) Object Hierarchy (Phân cấp đối tượng) Ring Mơ hình bảo mật hướng đến tính tồn vẹn liệu (chứ khơng phải bảo mật) đặc trưng cụm từ: "đọc lên, ghi lại" Điều trái ngược với mơ hình BellLaPadula đặc trưng cụm từ "đọc xuống, viết lên" Mô hình Biba định nghĩa tập hợp quy tắc bảo mật, hai quy tắc tương tự mơ hình BellPad LaPadula Hai quy tắc mặt trái quy tắc BellPad LaPadula: Thuộc tính tồn vẹn đơn giản nói chủ thể mức tồn vẹn định khơng đọc liệu mức toàn vẹn thấp (đọc lên) Read Read Read “no read-down” Thuộc tính tồn vẹn nói chủ thể mức tồn vẹn định khơng ghi vào liệu mức tồn vẹn cao (ghi lại) “no write-up” Một quy trình từ bên khơng thể u cầu quyền truy cập cao hơn; với đối tượng mức thấp Strict Integrity Policy Chính sách sách phổ biến sử dụng từ mơ hình “no write-up” and “no read-down” liệu hệ thống, điều đối lập với mơ hình Bell LaPadula Chính sách hạn chế nhiễm liệu mức cao hơn, đối tượng phép sửa đổi liệu cấp độ họ mức độ thấp “No Write Up" điều cần thiết, hạn chế thiệt hại mà thực đối tượng nguy hiểm hệ thống Ví dụ,“No Write Up" hạn chế số thiệt hại mà thực Trojan hệ thống Các trojan ghi tới đối tượng cấp độ nguyên vẹn thấp Điều quan trọng hạn chế thiệt hại mà gây cho Hệ điều hành “No read-down” ngăn ngừa chủ thể không bị ô nhiễm đối tượng tin cậy Thuận lợi Bất lợi Thuận Lợi: Mơ hình Biba đơn giản dễ thực Mơ hình Biba cung cấp số sách khác lựa chọn dựa nhu cầu Bất Lợi: Mơ hình khơng thực thi tính bảo mật Mơ hình Biba không hỗ trợ việc cấp thu hồi quyền Để sử dụng mơ hình này, tất máy tính tron hệ thống phải hỗ trợ ghi nhãn toàn vẹn cho chủ thể đối tượng Đến này, khơng có giao thức mạng hỗ trợ việc ghi nhãn .. .Bài tập lớn mơn An tồn hệ điều hành Nhóm Đề bài: Xây dựng tình hệ thống file  Tuân thủ vi phạm yêu cầu hệ thống file  Kiểm tra tình Alloy Xây dựng mơ hình an tồn Bell-La Padula... tệp tin hệ điều hành nằm thư mục  Hệ thống file có số ràng buộc để chắn đối tượng hoạt động theo cách người dùng kỳ vọng Ví dụ quan hệ cấp (parent) nội dung (content) cần không mang quan hệ với... nguy hiểm hệ thống Ví dụ,“No Write Up" hạn chế số thiệt hại mà thực Trojan hệ thống Các trojan ghi tới đối tượng cấp độ nguyên vẹn thấp Điều quan trọng hạn chế thiệt hại mà gây cho Hệ điều hành “No

Ngày đăng: 05/06/2020, 18:05

Từ khóa liên quan

Mục lục

  • b) Các tình huống vi phạm các yêu cầu của hệ thống file

  • Không có file root nào trong hệ thống file.

  • Hệ thống file chỉ có duy nhất một thư mục gốc Root và tập các đối tượng của hệ thống file là tập con của bất cứ đối tượng nào truy nhập được từ thư mục gốc Root. Chúng ta kiểm tra bằng 2 câu lệnh bên dưới đây:

    • Ta nhận được cả 3 kết quả “No counterexample found. Assertion may be valid.”, điều đó có nghĩa là không có vấn đề được tìm thấy đối với mỗi kiểm tra.

    • b) Các tình huống vi phạm hệ thống file:

Tài liệu cùng người dùng

Tài liệu liên quan