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

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 TOÀN HỆ ĐIỀU HÀNH

Giảng viên : Phạm Hoàng Duy

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

Nhóm 7

Đề bài:

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

I 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

1 Tuân thủ và vi phạm các yêu cầu của hệ thống file:

a) Các tình huống tuân thủ các yêu cầu của hệ thống file

- Đường dẫn trong hệ thống file không tuần hoàn.

Trong hệ thống file, sẽ không có thư mục nào chứa chính nó nghĩa là quan hệ giữa các thư mục không quay vòng Để kiểm tra các thuộc tính của hệ

thống cần xây dựng các khai báo assert và dùng lệnh check để yêu cầu Alloy kiểm tra các phản ví dụ cho các mệnh đề khẳng định Khai báo fact bắt buộc mệnh đề phải đúng còn assert cho rằng một số thứ phải đúng do hành vi của

mô hình Như vậy quan hệ này được thể hiện như là tập đóng bắc cầu và khai báo thông qua toán tử:

assert acylic {

no d: Dir \ in d.^contents // không có thư mục nào chứa chính nó }

Để kiểm tra mô hình với tối đa 5 đối tượng FSObject sử dụng câu lệnh sau:

check acyclic for 5 // kiểm tra mô hình với tối đa 5 đối tượng object.

Khi kiểm tra, Alloy sẽ xem xét các trường hợp mà mức cao nhất của các đối tượng có tối đa là 5 Có thể có hai kết quả:

 “no solution found” nghĩa là không có phản ví dụ đối với câu khẳng định

của mô hình với phạm vi kiểm tra hiện thời

 “solution found” nghĩa là có phản ví dụ Ví dụ này có thể được biểu diễn

dưới dạng đồ họa

- Mỗi File System Object(FSObject) nằm nhiều nhất trong một Directory

 Mỗi file tệp tin trong hệ điều hành chỉ có thể nằm ở trong một thư mục duy nhất

 Hệ thống file có một số ràng buộc cơ bản để chắc chắn các đối tượng hoạt

động theo cách người dùng kỳ vọng Ví dụ như quan hệ cấp trên (parent)

và nội dung (content) cần không mang bất cứ quan hệ gì với nhau Ngoài

ra, có quan hệ ràng buộc tường minh là một thư mục là cấp trên với các đối tượng chứa bên trong nó

 Hay với bất kỳ thư mục d nào và bất kỳ o thuộc về nội dung contents của

d thì cấp trên của o chính là d Nếu không có ràng buộc này thì sẽ có tình

huống, File có cấp trên là thư mục gốc Root hay một thư mục có cấp trên

chính là nó

 Phát biểu fact thể hiện một ràng buộc tường minh của mô hình Alloy tìm

kiếm các ví dụ (trạng thái hệ thống thỏa mãn ràng buộc) thì các ví dụ vi phạm ràng buộc bị loại bỏ Nếu ràng buộc bị lỗi thì sẽ không thể tìm thấy

ví dụ nào cả

 Khi khai báo Dir và File thừa kế FSObject nghĩa là không có đối tượng

FSObject có thể vừa là File vừa là thư mục Dir Nhưng cần có ràng buộc

không có FSObject nào không thuộc về một trong hai loại đối tượng trên.

 Để kiểm tra tính đúng đắn của tình huống trên ta sẽ dùng 2 câu lệnh:

assert oneLocation {

all o: FSObject | lone d: Dir | o in d.contents }

check oneLocation for 5

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:

assert noRoot {

no d: Dir | no d.parent // tất cả directory đều parent }

check noRoot for 5

- Hai File System Object(FSObject) bất kì ( không phải root) đều có chung

parent

Chúng ta cùng xét mộ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 huống trên hoàn toàn không chính xác, vì mỗi FSObject đều

có riêng cho mình một parent Ta sẽ 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 3

2 Kiểm tra các tình huống này bằng Alloy:

- Hệ thống file (File System)

Ta kiểm tra các mô hình bằng cách tìm kiếm phản ví dụ Ở đây, Alloy sẽ kiểm

tra tất cả các hệ thống file với tối đa 5 đối tượng FSObject, và cố gắng tìm 1 hệ thống vi phạm khẳng định hiện thời

Khi kiểm tra được thực thi, có thể có 2 kết quả:

 no solution found nghĩa là không có phản ví dụ đối với câu khẳng định.

 solution found nghĩa là có phản ví dụ đối với câu khẳng định.

a) Các tình huống tuân thủ hệ thống file:

- Đường dẫn trong hệ thống file là 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 5

- Hệ thống file chỉ có 1 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 5

- Mỗi đối tượng có 1 chỗ trong 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 5

 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:

- Hai đối tượng bất kỳ (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 5

 Tìm được counterexample đối với assert hiện thời:

- Hệ thống file không tồn tại 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 5

 Tìm được counterexample đối với assert hiện thời:

- Đối tượng bất kỳ có nhiều hơn 1 chỗ trong 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 5

 Tìm được counterexample đối với assert hiện thời:

Xâ

y dựng mô hình an toàn Bell-La Padula và Biba

1 Mô hình Bell-La Padula.

Giới thiệu

Mô hình Bell-La Padula là một mô hình an toàn bảo mật phổ biến trong các lĩnh vực liên quan đến an ninh quốc phòng, được hình thức hóa trên mô hình bảo mật đa cấp MAC Mô hình chú trọng đến bảo vệ tính bí mật trong việc kiểm soát truy nhập của hệ thống

Các đặc trưng của mô hình này được diễn giải như sau:

 Quyền truy nhập được định nghĩa thông qua ma trận truy nhập và mức độ bảo mật của đối tượng và chủ thể

 Các chính sách an toà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 này chỉ xem xét luồng thông tin xảy ra khi có sự thay đổi hay quan sát một đối tượng

Mô tả mô hình

Để thực hiện việc kiểm soát truy nhập mô hình này định nghĩa mức dộ an toàn cho các đối tượng dữ liệu và các chủ thể Các mức độ bảo mật được sử dụng là tối mật (Top Secret – TS), mật (Secret–S), nội bộ (Confidential–C) và Còn lại (Unclassified–UC)

Trong hệ thống có 2 hiệu ứng tác động khi một chủ thể truy xuất lên thông tin của đối tượng đó là: “obseving” có nghĩa là đọc thông tin của đối tượng và

“alerting” ghi thông tin vào đối tượng Tương ứng với 2 loại hiệu ứng này ta có

4 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 giờ chúng ta sẻ bắt đầu mô tả máy trạng thái của mô hình này

Trước tiên ta sẻ có một số ký hiệu thể hiện các thông tin cơ bản như sǀS chủ thể

và tập các chủ thể, oǀO đối tượng và tập các đối tượng, aǀA={e,r,a,w} tập các quyền truy xuất Một trạng thái sẽ được định nghĩa là bộ ba (b,M,F) trong đó

 b=(s,o,a) current access set Bộ 3 giá trị thể hiện đối tượng s sẻ thực hiện truy xuất a lên đối tượng o

 M access permission Là một ma trân truy xuất có giá trị các phần từ Mij lưu lại các quyền truy xuất mà chủ thể Si có thể tác động lên đối tương Oj.

 f=(fs ,fc ,fo) level function Là một bộ ba thể hiện mức độ bảo mật của các chủ thể và đối tượng tại trạng thái hiện tai Trong đó fs là mức bảo mật cao nhất của chủ thể s, fo là mức bảo mật của đối tượng o và cuối cùng fc là mức

độ bảo mật hiện tại của chủ thể s

Chính sách

Bộ chính sách Bell-La Padula chỉ có 2 luật cơ bản được phát biểu hết sức đơn giản Luật thứ nhất được gọi là Simple Security Property, ký hiệu là ss-property, luật thứ 2

là * Property, ký hiệu là *-property 2 luật này được phát biểu chi tiết như sau

 ss-property:

Thuộc tính này được thỏa mãn khi với mỗi bộ truy xuất b (s,o,a) mà truy xuất a có thuộc tính observe thì mức độ bảo mật cùa s phải lớn hơn hoặc bằng mức độ bào mật của o

Hay nói rõ hơn (b,M,f) thỏa mã tính chất ss-property khi b(s,o,a=read/write) thì fo ≤ fs.

Xét biểu đồ luồng thông tin trên ta thấy S2 theo một cách gián tiếp có thể đọc dữ liệu từ đối tượng O1 hay có thể nói luồng dữ liệu từ mức cao rò rỉ xuống mức thấp Để tránh tình trạng này ta sẻ có thính chất thứ 2

 *-property:

Thuộc tính này được thỏa mãn khi với bất kì tràng thái nào nếu một chủ thể

s thực hiện truy xuất observe tới đối tương o1 và thực hiện truy xuất alert tới o2 thì mức độ bảo mật của o1 phải lớn hơn mức độ bảo mật của o2 Rõ ràng tính chất này không cho phép trường hợp trên xảy ra

Cũng theo tính chất này chúng ta cũng có thể phân chia các cấp độ của các đối tượng được truy xuất từ một chủ thể nhất định

Chúng ta sẽ định nghĩa lại luật thứ theo current-level như sau: Trạng thái (b,M,f) thỏa mãn tính chất khi với bộ truy xuất b(s,o,a) có

a=append khi fo < fc, a=write khi fo = fc, a=read khi fo > fc

Có 1 điểm đáng chú ý là thuộc tính thứ 2 không áp dụng cho chủ thể tin cậy: Chủ thể tin cậy là chủ thể đảm bảo sẽ không vi phậm chính sách ngay cả khi

có thể

Ưu nhược điểm

Ưu điểm:

 Là cơ chế có tính bảo mật cao, thịch hợp trong môi trường như quân đội và chính phủ.

Nhược điểm:

 Mô hình chỉ tập trung vào tính bảo mất, không đảm bảo tính toàn vẹn thông tin

 Không linh động trong việc thay đổi quyền truy cập

 Mô hình không chặn được convert chanel nghĩa là một chủ thể ở mức bảo mật thấp có thể phát hiện sự hiện diện của một đối tượng ở mức bảo mật cao khi chủ thể đó thực hiện true xuất đến đối tượng mà bị từ chối

 Không hỗ trợ tính đa thể hiện

 Quá chặt chẽ nên khó áp dụng trong các mô hình đời sống

Ví dụ: Trong một công ty có các thành phần sau: ban giám đốc, trưởng phòng, các nhân vên khác tương ứng với đó là 3 lọai tài liệu, tài liệu các hợp đồng công ty, tài liệu nhân sự, và tài liệu công việc Công việc chúng ta bây giờ sẽ làm sao cho những tài liêu ở mức cao không tuồn xuống các nhân viên cấp thấp hơn Áp dụng mô hình ta có:

Ban giám đốc sẽ có quyền đọc nhưng không thể tuần tài liệu cấp cao xuống mức dưới Các truỏng phòng sẽ có quyền đọc và thay đổi tài liệu nhân sự và tài liệu công việc, có thể biết về sự tồn tại hợp đồng và có thể góp ý Còn nhân viên thì có thể biết về sự tồn tại của các tài liệu trên và có thể góp ý nhưng không được đọc và thay đổi bất kỳ nội dung nào ngoài tài liệu công việc

1 Mô hình toàn vẹn Biba

Năm 1977, Biba đề xuất một mô hình (sau này được gọi là mô hình Biba) xử lý tính toàn vẹn của hệ thống khi các chủ thể thực hiện truy xuất các đối tượng sử dụng

mô hình máy bảo mật tương tự như mô hình BLP

Integrity (Tính toàn vẹn)

Tính toàn vẹn đề cập đến sự tin cậy của dữ liệu hay tài nguyên Tính toàn vẹn thường được xác định trong điều khoản ngăn chặn thay đổi không phù hợp của dữ

liệu Có ba mục tiêu tính của tính toàn vẹn:

 Ngăn chặn người sử dụng trái phép sửa đổi dữ liệu hay chương trình

 Ngăn chặn người dùng được ủy quyền sửa đổi không phù hợp hay trái phép

 Duy trì tính thống nhất nội bộ và bên ngoài của dữ liệu và chương trình

Set Categories (Thiết lập danh mục)

Tập các loại chứa trong nhãn sẽ là một tập hợp con của tất cả các bộ trong hệ thống Việc phân loại tập hợp các loại là không theo thức bậc

Ví dụ Set Categories

Một ví dụ về hai loại là loại X = (Detroit, Chicago, New York thể loại) và Y = (Detroit, Chicago) Trong trường hợp này X ≥ Y (X dominates Y), vì Y là một tập hợp con của X Nếu có loại Z (Detroit, Chicago, Miami) Z và X trong trường hợp này là không thể so sánh bởi vì các yếu tố thứ ba của bộ này là khác nhau

Integrity Levels (Cấp độ toàn vẹn)

Mỗi cấp độ toàn vẹn sẽ được đại diện bởi L (C, S), trong đó:

 L là mức toàn vẹn

 C là phân loại

 S là danh mục

Các mức toàn vẹn sau đó hình thành một mối quan hệ thống trị Mức toàn vẹn L =₁ = (C , S ) trội hơn (≥) mức toàn vẹn L = (C , S ) nếu và chỉ nếu: C ≥ C and S ₁ = ₁ = ₂ = (C₂, S₂) nếu và chỉ nếu: C₁ ≥ C₂ and S₁ ₂ = (C₂, S₂) nếu và chỉ nếu: C₁ ≥ C₂ and S₁ ₂ = (C₂, S₂) nếu và chỉ nếu: C₁ ≥ C₂ and S₁ ₁ = ₂ = (C₂, S₂) nếu và chỉ nếu: C₁ ≥ C₂ and S₁ ₁ = ⊇ S₂ = (C₂, S₂) nếu và chỉ nếu: C₁ ≥ C₂ and S₁

Chủ thể và đối tượng

Cũng giống như các mô hình khác, mô hình Biba hỗ trợ kiểm soát truy cập của chủ thể và các đối tượng

 Subjects (chủ thể) là những yếu tố hoạt động trong hệ thống có thể truy cập

thông tin

cầu (files, programs, etc.)

Mỗi chủ thể và đối tượng trong mô hình Biba sẽ có một mức độ toàn vẹn gắn với nó

Access Modes (Chế độ truy cập)

Mô hình Biba bao gồm các phương thức truy cập sau:

Biba Policies (Chính sách của mô hình)

Mô hình Biba thực sự là một nhóm các chính sách khác nhau có thể được sử dụng

Mô hình này được hỗ trợ cả chính sách bắt buộc và chính 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 toàn vẹn nghiêm ngặt)

 Low-Watermark Policy for Subjects: Chính sách này giảm mức toàn vẹn xuống mức chủ thể đọc xuống dựa theo các đối tượng đang được quan sát

 Low-Watermark Policy for Objects: Giảm mức đối tượng xuống với chủ thể đang ghi

 Low-Watermark Integrity Audit Policy: Bất kỳ chủ thể nào cũng có thể sửa bất

kỳ đối tượng nào, bất kể mức toàn vẹn

 Ring Policy: Bất kỳ chủ thể nào cũng có thể quan sát bất kỳ đối tượng nào, bất

kể mức độ toàn vẹn

The Discretionary Policies (Chính sách tùy ý):

1 Access Control Lists (Truy cập vào danh sách điều khiển)

2 Object Hierarchy (Phân cấp đối tượng)

3 Ring