Báo cáo bài tập lớn môn An toàn hệ điều 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:


II.

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ừ M ij 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 đó f s 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 f c 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 ₁ ⊇ 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.
 Objects (đối tượng) là những yếu tố thụ động mà truy nhập có thể được yêu
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:





Modify (Sửa đổi): Cho phép một chủ thể ghi một đối tượng.
Observe (Quan sát): Cho phép một chủ thể đọc một đối tượng.
Invoke (Triệu gọi): Cho phép một chủ thể giao tiếp với chủ thể khác.
Execute (Thực hiện): Cho phép một chủ thể thực hiện một đối tượng.

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
Mô hình bảo mật này hướng đến tính toàn vẹn dữ liệu (chứ không phải bảo mật) và
được đặc trưng bởi cụm từ: "đọc lên, ghi lại". Điều này trái ngược với mô hình BellLaPadula được đặc trưng bởi cụm từ "đọc xuống, viết lên".


Mô hình Biba định nghĩa một tập hợp các quy tắc bảo mật, hai quy tắc đầu tiên tương
tự như mô hình BellPad LaPadula . Hai quy tắc đầu tiên này là mặt trái của quy tắc

BellPad LaPadula:
1. Thuộc tính toàn vẹn đơn giản nói rằng một chủ thể ở mức toàn vẹn nhất định
không được đọc dữ liệu ở mức toàn vẹn thấp hơn (đọc lên).

Read
Read

Read

“no read-down”
2. Thuộc tính toàn vẹn nói rằng một chủ thể ở mức toàn vẹn nhất định không
được ghi vào dữ liệu ở mức toàn vẹn cao hơn (ghi lại).

“no write-up”
3. Một quy trình từ bên dưới không thể yêu cầu quyền truy cập cao hơn; chỉ với
các đối tượng ở mức bằng hoặc thấp hơn.
Strict Integrity Policy
Chính sách này là chính sách phổ biến nhất được sử dụng từ mô hình.
“no write-up” and “no read-down” trên dữ liệu trong hệ thống, điều này đối lập
với mô hình Bell LaPadula.
Chính sách này hạn chế ô nhiễm của các dữ liệu ở mức cao hơn, vì đối tượng là
chỉ được phép sửa đổi dữ liệu ở cấp độ của họ hoặc ở mức độ thấp hơn
“No Write Up" là điều cần thiết, vì nó hạn chế thiệt hại mà có thể được thực
hiện bởi các đối tượng nguy hiểm trong hệ thống. Ví dụ,“No Write Up" hạn chế
số thiệt hại mà có thể được thực hiện bởi một Trojan trong hệ thống. Các
trojan sẽ chỉ có thể ghi tới các đối tượng ở cấp độ nó nguyên vẹn hoặc thấp
hơn. Điều này quan trọng bởi vì nó hạn chế những thiệt hại mà có thể được gây
ra cho Hệ điều hành
“No read-down” ngăn ngừa một chủ thể không bị ô nhiễm bởi một đối tượng ít
tin cậy.

Thuận lợi và Bất lợi


Thuận Lợi:
1. Mô hình Biba đơn giản và dễ thực hiện.
2. Mô hình Biba cung cấp một số chính sách khác nhau có thể lựa chọn dựa trên
nhu cầu.
Bất Lợi:
1. Mô hình này không thực thi tính bảo mật.
2. Mô hình Biba không hỗ trợ việc cấp và thu hồi quyền.
3. Để sử dụng mô hình này, tất cả các máy tính tron hệ thống phải hỗ trợ ghi nhãn
toàn vẹn cho cả chủ thể và đối tượng. Đến này, không có giao thức mạng hỗ trợ
việc ghi nhãn này.