Kiểm chứng đặc tả bảo mật phần mềm

ĐẠI HỌC QUÔC GIA HÀ NỘI
KIỂM CHỨNG ĐẶC TẢ BẢO MẬT PHẦN MÈM
M â số: QC.09.01
C hủ nhiệm đề tài: T S. T rư ơng N inh T huận
OẠI HỌC Q u ó c G ia h a n o i
ĩttUNG TẨM THÒNG TIN THƯ VIEN
0 0 0 6 0 0 0 0 0 ^ 6
Hà Nội - 2010
Mục lục
1 Phần mở đ ầ u 1
1.1 Danh sách những người tham gia thực hiện đề tài . . . 1
1.2 Báo cáo đề t à i 1
2 Phần nội dung c h í n h 3
2.1 Đ ặt vấn đề 3
2.2 Tổng quan các vấn đề nghiên c ứ u 4
2.3 Dề x uất giải pháp kiểm chứng đặc tả bảo m ật phần mềm 6
3 Kết luận và kiến n g h ị 8
i
Danh sách hình vẽ
1 RBAC m o d e l 4
2 Cú pháp L r b a c 6
3 Dạng AST của lệnh If, lệnh While, và lệnh F o r

7
ii
1 Phần mở đầu
1.1 Danh sách những người tham gia thực hiện đề tài
S T T .
H ọ tê n N ơi côn g tá c
1 Thíơng Ninh Thuận Trường ĐH Công nghệ
2

Nguyễn Việt Hà Trường ĐH Công nghệ
3
Vũ Quang Dũng Trường ĐH Công nghệ
4 Trương A nh Hoàng IVường ĐH Công nghệ
1.2 Tóm tắt đề tài
T ên đ ề tà i: Kiểrri chứng đặc tả bảo m ật phần mềm (security policy)
M ã số đ ề tà i: QC.09.01
C h ủ n h iệm đ ề tà i:
• Họ và tên: Từương Ninh Thuận Giới tính: nam
• Năm sinh: 1977
• Chuyên môn đào tạo: Công nghệ thõng tin
• Học hàm, học vị: Tiến sĩ
• Đdn vị công tác: Khoa Công nghệ thông tin, Trường Đại học Công
nghệ, Đại học Quốc gia Hà Nội.
• Địa chỉ liên hệ: P309 nhà E3, 144 Xuân Thủy, Cầu Giấy, Hà Nội.
• Số điện thoại: (04) 7549016 Fax: (04) 7680460
• Email: thuantn@ vnu.edu.vn
K ế t q u ả đ à o tạo : Đã hướng dẫn 02 sinh viên làm khóa luận theo hướng
nghiên cứu của đề tài và bảo vệ vào tháng 06 /2 0 ^ 0
• Nguyễn Thị T hanh Thủy, Nghiên cứu về an ninh dịch vụ web, Trường
ĐH Công nghệ, 2010
• Phạm M ạnh Hùng, Nghiên cứu đặc tả UML security, Trường DH Công
nghệ, 2010
1
K ế t q u ả k h o a h ọ c v à cô n g nghệ:
Tóm tắt nội dung và kết quả nghiên cứu:
Sự p hát triển nhanh chóng của phần mềm trong tất cà các lĩnh vực của
cuộc sống và những lợi ích mà nó mang lại cho con người đã được khảng
định. Tuy nhiên, bên cạnh những lợi ích to lớn này, các hệ thống phần mềm
cũng có thể gây ra những hậu quả khó lường nếu xuất hiện các lỗi trong lúc

vận hành. Những thách thức này đòi hỏi những người nghiên cứu về CNTT
cần phải có những giải pháp thích hợp để quản lý và phát triển các hệ thống
phần mềm m ột cách chắc chắn và tin cậy.
Đặc tả cơ chế bảo m ật (security policy) liên quan đến việc kiểm soát truy
cập vào hệ thống của nhiều người sử dụng dựa trên nhiều vai trò khác nhau
của họ. Mục đích của security policy là mô tả những ràng buộc chung để
kiểm soát việc truy cập vào tài nguyên hệ thống m à không quan tâm đến
chi tiết việc cài đặt. Mỗi người sử dụng hệ thống sẽ được gán một vai trò,
mỗi vai trò có quyền truy cập đến các đối tượng và các chức nẫng nào của
hệ thống phải tuân theo các đặc tả về an ninh của hệ thống.
TVong khuôn khổ của đề tài này, chúng tôi tập trung nghiên cứu để đóng
góp các giải pháp khác nhằm hạn chế các lỗi của chương trình liên quan đến
security policy, các giải pháp này bao gồm việc tích hợp các ràng buộc liên
quan đến security policy và hệ thống phần mềm và làm thế nào để kiểm
chứng được đặc tả và thực thi của hệ thống phần mềm tuân theo những ràng
buộc này.
Các bài báo khoa học đã công bố trong phạm vi đề tài: Dã báo cáo ở 01
hội nghị khoa học quốc tế có phản biện:
• Tuan-Hung Pham , Ninh-Thuan Truong, Viet-Ha Nguyen. Analyzing
R B A C Security Policy of Implementation Using AST. In proceeding of
International Conference on Knowledge and Systems Engineering (KSE
2009). Hanoi, Vietnam, pp. 215-219, 2009.
K ế t q u ả tă n g cư ờn g tiề m lực cho đ ơ n vị: Đào tạo được một số cán
bộ có hiểu biết về kiểm chứng phần mềm, có khả năng nghiên cứu chuyên
sâu và xây dựng các công cụ phục vụ mục đích kiểm tra các tính chất về an
ninh hệ thống và về sự tin cậy của phần mềm.
2
2 Phần nội dung chính
2.1 Đặt vấn đề
Sự phát triển nhanh chóng của phần mềm trong tấ t cả các lĩnh vực của cuộc

sống và những lợi ích m à nó mang lại cho con người đã được khẳng định.
Tuy nhiên, bên cạnh những lợi ích to lớn này, các hệ thống phần mềm cũng
có thể gây ra những hậu quả khó lường nếu xuất hiện các lỗi trong lúc vận
hành. Những thách thức này đòi hỏi có những phương pháp kiểm chứng hiệu
quả để phát hiện các lỗi phần mềm trước khi đưa vào sử dụng trong thực tế.
Trong phát triển phần mềm, đặc tả có nhiệm vụ đưa ra các mô. tả và
ràng buộc ban đầu cho hệ thống phần mềm, giúp những người phát triển
hiểu được chính xác các chức năng, nhiệm vụ, hoạt động của hệ thống. Lập
trình viên, dựa trên những tài liệu đặc tả này, sẽ xây dựng hệ thống phần
mềm bằng các ngôn ngữ lập trình khác nhau. Tuy nhiên, chương trình sau
khi xây dựng có thể sẽ không thỏa mãn m ột số ràng buộc trong các tài liệu
đặc tả.
Điều khiển truy cập trong hệ thống phần mềm là cơ chế an ninh cho phép
người sử dụng có các quyền truy cập vào dữ liệu theo các mức khác nhau,
tùy theo vai trò của người sử dụng. Nói cách khác, mục đích của điều khiển
truy cập là bảo toàn tính bảo m ật và toàn vẹn của hệ thống. Trong các kỹ
thuật thường hay được sử dụng để điều khiển truy cập, DAC (Discretionary
Access Control), MAC (M andatory Access Control) và RBAC (Role-Based
Access Control) là các kỹ thuật mới nhất và hiệu quả n hất trong các ứng
dụng thương mại và hệ thống quân sự, dựa trên tiềm năng về cấp phép quyền
truy cập, giảm chi phí quản trị và phòng ngừa các lỗi xảy ra trong các hệ
thống lớn [4]. Trong đề tài này, chúng tôi chọn EBAC là ngôn ngữ mô tả cơ
chế an ninh cho hệ thống.
Khi m ột hệ thống phần mềm cần bảo mật, các cơ chế bảo m ật càn phải
được đặc tả và thực thi cùng với các yêu cầu khác của hệ thống. Tuy nhiên,
việc đặc tả và thực thi hệ thống có thể được thực hiện bời những người khác
nhau và trong những thời gian khác nhau, điều này dẫn đến vấn đề thực thi
không cài đặt đúng đặc tả an ninh của hệ thống.
Vấn đề tuân theo giữa thiết kế RBAC và thực thi hệ thống đã được xem
xét về m ặt lý thuyết tro ng các nghiên cứu của Hansen và Oleshchuk [5| và

Anrưnar et al. [1], Tuy nhiên, các nghiên cứu này vẫn chưa xem xét kiểm
tra xem việc thực thi chương trình có phù hợp với đặc tả hay không. Đề tài
nghiên cứu này đóng góp m ột phương pháp kiểm tra sự phù hợp vởi đặc tả
RBAC của m ã nguồn chương trình bằng cách phân tích cây cú pháp trừu
tượng AST {Abstract Syntax Tree).
3
2.2 Tổng quan các vấn đề nghiên cứu
TVong một mô hình điều khiển truy cập dựa trên vai trò (RBAC) [4], users
dùng để chỉ những người tương tác trực tiếp với hệ thống. Những người sử
dụng này có thể tạo ra các tiến trình của máy tính, những tiến trình này gọi
là subjects trong RBAC. Bởi vì những tiến trình này thực hiện thay thế vai
trò của người sử dụng, các hoạt động của các subjects cần phải được kiểm
tra dựa trên đặc quyền của người sử dụng, được gọi là roles. Roles (vai trò),
được coi như là 'trun g tâm của RBAC, được gán không những cho người sử
dụng sỏ hữu nó, m à cả quyền có thể làm gì. Mỗi quyền (permission) trong
RBAC là một cặp operation và object, nghĩa là quyền cho phép đối tượng
được xử lý bởi thao tác nào của người sử dụng.
Quan hệ giữa các thành phần trong mô hình RBAC được mô tả trong
Hình 1. Trong báo cáo này, chúng tôi sử dụng u, r,p, op, và 0 để chỉ người sử
dụng (user), vai trò (role), quyền hạn (permission), thao tác (operation), đối
tượng tác động (object).
Hình 1: RBAC model
Đ ịn h ng h ĩa 2.1 (M ô h ìn h R B A C ) Một mô hình R BA C gồm những thành
phần sau:
• U ,7 l,V ,Õ p ,0 , và s (users, roles, permissions, operations, objects,
subjects).
• -Ann c u X 71, quan hệ nhiều-nhiều từ users đến roles.
• A nv Q 71 X 'P, quan hệ nhiều-nhiều từ roles đến permissions.
• role_u sers, quan hệ một-nhiều từ role r € 71 dến users có kết nối:
role_users(r) = {u 6 u I (u, r) € Auv.)

• role_perm issiơns, quan hệ một-nhiều từ vai trò r e 71 đến permis
sions:
4
ro le_ p erm issiơ n s(r) = {p € V I (r,p) € A n p }
• su bjed _ use r, quan hệ m ột nhiều từ subject dến user tương ứng.
su bject_ u ser(s) = u € U , s được tạo bởi u
• su b je ă _ ro le s, quan hệ một nhiều từ subject đến roles:
subject_roles(s) = {r € Tl I su b je ă _u se r(s ) € ro /e_ iisers(r)}
RBAC có hai tính chất quan trọng được định nghĩa trong Định nghĩa 2.2
và Định nghĩa 2.3,
Đ ịn h n g hĩa 2.2 (R o le a u th o riz atio n ) Vs € S,V r e subject_roles{s)
=> (su b je đ _ u se r (s ),r) 6 A u n
Đ ịn h n g hĩa 2.3 ( O b je ct access a u th o riz atio n ) [u, (op,o)J = 3p 6 V, 3r €
TZ : p = (ọp,o),p € ro le_perm ission s(r) A íiE ro le_ users(r)
T ừ khi RBAC lần đầu được đề xuất bởi các tác giả Ferraiolo và Kuhn [3]
và cải tiến bởi các nghiên cứu [8, 7, 6], nó đã trỏ thành một ngôn ngữ được
sử dụng rộng rãi trong nghiên cứu đặc tả an ninh phần mềm.
Cũng là một nghiên cứu về cơ chế bảo m ật phần mềm, Tschantz và W ing
[9] giới thiệu một phương pháp để trích chọn các điều kiện bảo m ật từ mã
nguồn chương trình. Bài báo này chủ yếu nghiên cứu để lấy ra được những
cơ chế bảo m ật ẩn của m ột thực thi phần mềm.
Sự kiểm tra tuân theo giữa đặc tả RBAC và phần thực thi cũng đã được
nghiên cứu trong các bài báo [5] và [1]. Hansen and Oleshchuk [5] đề xuất một
giải pháp sử dụng Linear Temporal Language để biểu diễn các điều kiện bảo
m ật và ngôn ngữ PROM ELA để minh họa phần thực thi. Gần đây, Ammar
et al. [1] cũng hướng đến kiểm chứng vấn đề này những lại sử dụng kỹ thuật
Test phần mềm. Nghiên cứu của chúng tôi khác hoàn toàn với các nghiên
cứu này, chúng tôi phân tích cây cú pháp trừu tượng của chương trình để
kiểm tra sự tuân theo giữa thực thi và đặc tả RBAC.
5*

2.3 Đề xuất giải pháp kiểm chứng đặc tả bảo mật phần
mềm
Mỗi cài đặt của RBAC cần phải được viết bởi một ngôn ngữ lập trình nào
đó, ví dụ như C + + hoặc Java. Tuy vậy, cú pháp của các ngôn ngữ lập trình
đó tương đối phức tạ p đối với việc phân tích RBAC. Do đó, trong đề tài này
chúng tôi chỉ quan tâm tới ba tập lệnh sau: các lệnh gán, các lệnh m à có
truy cập tới tài nguyên hệ thống, và các lệnh rẽ nhánh, được thể hiện qua
một ngôn ngữ trừ u tượng đơn giản L r b a c để viết các cài đật RBAC. Hình
2 mô tà cú pháp của L r b a c dưới dạng biểu diễn BNF:
s
Lệnh
(1)
v-< E Gán
(2)
1
Tuần tự
(3)
1 op(o,{£})
Thao tác
(4)
1
ử
(£ ) 5 [5]
ỉf-then-else
(5)
1 while (£ )
s
Lặp While
(6)
ị /o r (({ S (1)}];Ị£];[{S(1)}])S Lặp For

ĩ
• •
___
Biểu thức
(1)
V
Biến
(2) 1 c
Hằng
(3)
1 E ® E
Hình 2: Cú pháp L r b a c
Phép toán
Trong hình 2, [ ] chỉ các phần tử có thể có hoặc không, {} chỉ các phần tử
xu ất hiện nhiều lần, và I chỉ các lựa chọn. Phép gán ~< trong 5(1) có thể ỉà
các phép gán toán học (=, +=, -=, *=, /- , **), các lệnh gán dịch chuyển
bit (<=, >=, » = ) , hoặc các phép gán logic (Ề=, l=). Tương tự vậy, phép ©
trong E(3 ) có thể là các thao tác toán học (+, *, / , '/„ ), các lệnh dịch
chuyển bit (c, >, »>), hoặc các lệnh logic (I, ft, ==, !=, <, >, <=, >=).
Do ta có thể chuyển mọi công thức mệnh đề thành công thức dưới dạng
chuẩn hội (CNF) bằng cách áp dụng các luật hai lần phủ định, luật De
Morgan, và luật phân phối [2], mọi biểu thức có thể được viết lại thành dạng
hội của các thành phần. Nếu biểu thức trong S(4 )(5)(6) có dạng một tập hợp
các hội, ta có thể chuyển các hội đó thành các lệnh if kế tiếp nhau. Ví dụ:
if (E k E ) s [51 con” ri ự (E ) {if(E') s [5]}
while (E & E ) r T ' while (E) { if (E ’) S}
6
for (({%}]; E t E '; ị{s(1)}]) s /o r ([{S(,[{S(„}|) {./(£') s}
Do đó, ta có thể giả sử rằng mọi biểu thức trong S(4 )(5 )(6 ) chỉ chứa tuyển
của các thành phần.

Vì mục tiêu của ta là kiểm tra sự thống nhất giữa cài đặt và đặc tả của
RBAC, ta cần phải tập trung phân tích các điều kiện trong đặc tả. Các lệnh
điều kiện được thể hiện qua lệnh If 5(4), lệnh W hile 5(5), và lệnh For 5(6)
trong L r b a c - Hình 3 thể hiện cú pháp và dạng AST của các lệnh này.
Hình 3: Dạng AST của lệnh If, lệnh While, và lệnh For
Theo giả định đ ã nói ỏ trên, các biểu thức trong-lệnh If 5(4), lệnh While
•5(5), và lệnh For 5(6) có cú pháp E = E ị E . Trong AST, điều đó có nghĩa
là nếu một nút thể hiện một biểu thức E = E\ I E ĩ I ••• I Ek thì nút đó sẽ có
k con và mỗi con sẽ tương ứng với một biểu thức con ỏ vế phải.
T h u ậ t to á n kiểm chứ n g
T huật toán 1 trình bày một phương pháp để kiểm chứng sự nhất quán giữa
cài đặt và đặc tả RBAC. Để cho đơn giản, thuậ t toán này không xét tới môi
trường đa nhiệm, có nghĩa là tại mỗi thời điểm chỉ có nhiều nhất một tiến
trình (đối tượng) tạo bởi người dùng. Trước khi đi vào chi tiết, chúng tôi giới
thiệu một số ký hiệu và định nghĩa được sử dụng trong thu ật toán:
• Nếu một nút n € A S T thể hiện một cú pháp của L r b a C i ta ký hiệu
quan hệ đó bằng c .
• Không cần quan tâm tới các s được tạo bởi người dùng, mỗi lần kiểm
tra ta sẽ duy trì một tập hợp Tuple của các bộ bốn phần tử (u , r, ơp, o).
Mỗi bộ thể hiện rằng người đùng u thực hiện hành động ơp trên đối
tượng o dưới quyền T. Các thành phần của mỗi bộ sẽ được thể hiện là
0 nếu như ta không biết giá trị của chúng, hoặc là một biến chứa giá
trị này, hoặc là m ột hằng số nếu như giá trị này là hằng số.
While-Statement So
For-Statement
-[Initializers]
- [Expression]
- [Updaten]
I
7

A lg o rith m 1: Kiểm tra sự thống nhất giữa cài đặt và đặc tả RBAC
In p u t : A S T : AST của m ã nguồn
In p u t : D B : Cơ sở dử liệu RBAC
O u tp u t: Đặc tả và cài đật có thống nhất với nhau
D a ta : n, no, n': Các nút của A ST
Procedure ASTTraversalCAST, D B)
b eg in
fo rall n G A S T do
if n c 5(3) th e n
if ~>isConformant(n) th en
|_ r e tu rn false
re tu rn true
en d
P roced ure isConform ant(no)
b eg in
n <- no
Tuple 4- {(OjC.no.op.no.o)}
re p e a t
if n c {S(1), 1?(1)(2)(3)} th e n
fo rall t e Tuple do
[_ t *- replace(t,n)
L r e tu r n
if n o E an d parent(n) c 5(4){5)(6) th e n
fo ra ll t € Tuple do
fo rall n' e children(n) do
[_ Tuple *— Tuple u rep la c e ^,n ')
Tuple <— Tuple \ {i}
n <— go_backvjards(n)
u n til n = A ST .rooi
fo rall t € Tuple do

if accept(t) th e n
L re tu r n true
re tu rn false
en d
g
Các giá trị của m ột bộ bốn phần tử t có thể được thay đổi bời các phép
gán. Nếu nú t n chứa các lệnh gán (5(1) và E( 1)(2 )(3 ) trong L r b a c ) naà
có tác động tới bộ t thì ta ký hiệu sự kiện này bằng replace(t, n). Ví
dụ, nếu ta có í = (Q, Q, w rite ,o) và nút n chứa lệnh gán o—< input.txt
thì replace(t} n) — (0,0, write, in put.txt).
Với mỗi bộ t = (u,r, op, o), ta cần phải biết liệu nó có vi phạm quyền
vai trò trong Định nghĩa 2.2 và quyền truy cập đối tượng trong Định
nghĩa 2.3 hay không. Nếu t không vi phạm, ta chấp nhận (accept) nó,
ngược lại t sẽ bị loại bỏ. Ta hình thức hóa accept như sau:
accept^U yT.ơp^)) =
(ơp, o) e V nếu u = 0
( r = 0 V ( l i .r ) € A n n )
Aịu, (op, o)J nếu u Ỷ 0
Thuật toán này có đầu vào là AST của phần cài đặt và một cơ sở dử liệu
RBAC và trả về kết quả của việc kiểm tra. Ý tưởng của th u ậ t toán như sau:
Đầu tiên, ta thăm tất cả các nút cùa AST. Mỗi khi tới m ột nút no m à có truy
cập, tác động vào tài nguyên hệ thống, ta tạo một Tuple mới và quay ngược
trỏ lại để cập nhật Tuple qua các lệnh gán và các biểu thức điều kiện. Nếu
ta gặp một lệnh gán, mỗi bộ í € Tuple sẽ bị thay đổi bởi thao tác replace.
Trong trường hợp ta gặp một biểu thức điều kiện với k tuyển, ta sao chép
ra k phiên bản của mỗi bộ í € Tuple và thực hiện replace mỗi phiên bản
với tuyển tương ứng của nó. Sau khi đã quay ngược trỏ lại xu ất phát từ nút
n 0 xong, nếu có bất kỳ t € Tuple nào m à có accept(t) = true thì nút no sẽ
nhất quán với D B. Quá trình này được tiếp tục cho tới khi ta gặp một nút
no mà vi phạm D B hoặc ta đã kiểm tra tới nút gốc của A S T . T huật toán

này đảm bảo tính dừng vì nó duyệt qua AST là một cây có hữu hạn nút.
3 Kết luận và kiến nghị
Liên quan đến các yêu cầu của đề tài nghiên cứu, chúng tôi nhận thấy rằng
chúng tôi đã hoàn thành đầv đỏ các mục tiêu đặt ra ban đầu của đề tài bao
gồm một báo cáo trẽn hội nghị quốc tế và hướng dẫn hai sinh viên thực hiện
luận văn theo hướng đề tài.
Về nội dung của đề tài, chúng tôi đã đưa ra được một phương pháp mới
liên quan đến kiểm chứng sự tương thích giữa thực thi và đặc tả cơ chế bào
mật phần mềm. RBAC, một ngôn ngữ mới và hiệu quả dựa trẽn vai trò người
sử dụng, được sử dụng để mô tả quyền truy cập người dùng. Khi kiểm chứng,
5
thay vì phân tích các lệnh m â nguồn, chúng tôi thực hiện phân tích cây AST
của nó.
Hiện tại chúng tôi chỉ mới đề xuất thuật toán kiểm chứng giữa hai giai
đoạn của phần mềm. Trong tương lai, chúng tôi sẽ hoàn thiện việc cài đặt
thuật toán này trên Eclipse platform để sử dụng CDT, một plugin có khả
năng sinh tự động m ã nguồn c thành một cây cú pháp trừu tượng AST.
AO
Tài liêu tham khảo
[1] M. Ammar, A. Ghafoor, and A. M athur. Conformance Testing of Tempo
ral Role-Based Access Control Systems. IEEE Transactions on Depend
able and Secure Computing, 2008.
[2] H. B. Enderton. A Mathematical Introduction to Logic, Second Edition.
Academic Press, 2000.
[3] D. Ferraiolo and R. Kuhn. Role-Based Access Control. In In 15th N IST-
N C SC National Computer Security Conference, pages 554-563, 1992.
[4] D. F. Ferraiolo, R. D. Kuhn, and R. Chandramouli. Role-Based Access
Control, Second Edition. Artech House, Inc., Norwood, MA, USA, 2007.
[5] F. Hansen and V. Oleshchuk. Conformance Checking of RBAC Policy
and its Implementation. In Proceedings o f the First Information Secu

rity Practice and Experience Conference (ISP E C 2005), pages 144-155.
Springer, 2005.
[6] R. Sandhu, D. Ferraiolo, and R. Kuhn. The NIST model for role-based
access control: towards a unified standard. In R B AC ’00: Proceedings of
the fifth A C M workshop on Role-based, access control, pages 47-63, New
York, NY, USA, 2000. ACM.
[7] R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and c. E. Youman. Role-Based
Access Control Models. Computer, 29(2):38-47, 1996.
[81 R. S. Sandhu, R. s. s, H. Y, E. J. Coyne, H. L. Feinstein, and c. E.
Youman. Role-Based Access Control: A Multi-Dimensional View. In
Proceedings o f the 10th Conference on Computer Security Applications,
pages 54-62, 1994.
[9] M. c . Tschantz and J. M. Wing. Extracting Conditional Confidentiality
Policies. In SEF M ’08: Proceedings of the 2008 Sixth IEEE International
Conference on Software Engineering and Formal Methods, pages 107-116,
2008.
11
P H Ụ LỤ C
Phụ lục gồm có:
• 01 báo cáo trong hội nghị KSE’09
• Bản sao Đề cương và Hợp đồng thực hiện đề tài nghiên cứu đã được
phê duyệt
• Phiếu tóm tắ t kết quả nghiên cứu của đề tài bằng tiếng Anh
• Phiếu đăng ký kết quả nghiên cứu KHCN
Đ A I HỌ C Q U Ọ C G IA HÀ N Ô l
ÍRUNG TẨM THÒNG TIN THƯ VIỀN
2009 International Conference on Knowledge and Systems Engineering
Analyzing RBAC Security Policy of Implementation Using AST
Tuan-Hung Pham , Ninh-Thuan Truong, Viet-Ha N guyen
College of Technology

Vietnam National University
144 Xuan Thuy, Hanoi, Vietnam
Email: {phamtuanhung, thuantn, hanv}@ vnu.edu.vn
Abstract-—Security policy b a critical property in software
applications which require high Ievelj of safety and security.
It has to be clearly specified in requirement documents and its
implementation must be conformed to tbe specification. In this
paper, we propose an approach to check if the implementation
is in accordance with its security policy specification. We use
the Abstract Syntax Tree (AST), another manner of expressing
the program, to analyze the source code and specify user
permission policy In software systems by Role-Based Access
Control (RBAC).
I . I n t r o d u c t i o n
Access control in software systems is a security mecha
nism having the ability to give each entity official permis
sions to do some particular activities. The aim of access
control is to preserve the confidentiality and integrity of a
system. Among the most widely-used techniques of access
control representation, RJBAC proves to be very effective
because of its potential for access authorization, decreasing
administration costs and preventing errors in large sys
tems [1].
If a software system needs to be secure, it is important to
be sure that all of the security policy is enforced by strong
mechanisms. There are organized methodologies and risk
assessment strategies to assure the completeness of security
policies and assure that they are completely enforced. In
reality of software development, however, RBAC policy and
its implementation may be created by different humans and

at different times; consequently, it raises the problem of
inconformity between the specification and implementation
of security policy.
The issues of consistency between RBAC design and
implementation have been explored in theoretical approaches
of Hansen and Oleshchuk [2] and Ammar et al. [3]. How
ever, these approaches did not check if source code of
a program is conformed to its specification. This paper
contributes an approach to check the conformity with RBAC
policies by analyzing the Abstract Syntax Tree (AST) of
the implementation. Our approach considers RBAC imple
mentation not only kernel programs but also user-defined
ones which use RBAC as a user permission description. The
overall checking approach, shown in Figure 1, consists of
the following steps:
• First, we define an absưact language used for the
implementation called L rb a c - The language only fo
cuses on RBAC’s features and ignores other commands
of normal programming languages. Based on L r b a c
syntax, we transform the input source code into a
corresponding AST of L r b a c
• Also, RBAC policy is explicitly written in the form of
a RBAC database schema, called D B . Since this Slep
is well-studied [1], we do not discuss in detail how to
construct a RBAC database from a RBAC policy for
brevity.
• Then, we propose an algorithm to traverse the AST to
check whether the implementation is conformed to the
design using RBAC database.
Violation report

Figure I. Static Checking RBAC Policy Using AST o f Implem entation
The rest of the paper is organized as follows. Section
II briefly introduces RBAC model. Section HI presents
L r b a c . a language for RBAC’s implementation used in
the paper. Section IV presents our approach to check the
conformity of RBAC policy and its implementation using
AST of source code. Section V shows a case study to demon
strate how our method works. Related work is discusscd in
Section VI. Section VII concludes the paper and gives some
directions for future work.
978-0-7695-3846-4/09 $26.00 © 2009 IEEE
DOI 10.1109/KSE.2009.23
215
II. Ro l e -B a s e d A c c e s s C on t r o l
In a Role-Based Access Control (RBAC) model [1], users
refer to human beings who interact with a computer system.
At the same time, a user may invoke several computer
processes. Such processes are called subjects in RBAC’s
notions, Since each process proceeds on behalf pf its user,
all activities of a subject need to be checked by basing
on the privileges of the subject’s user, which represents as
roles. As the center component of a RBAC system, roles
are assigned not only to users to define who hold them but
also to permissions to point out what they can do. Each
permission is a pair of an operation and an object, meaning
that the permission allows the object to be accessed by the
operation.
The relationship between the components in a core RBAC
model is depicted in Figure 2. Throughout the paper, we use
u,r,p,op, and 0 to denote a user, a role, a permission, an

operation, and an object, respectively.
Figure 2. RBAC model
Definition 2.1 (Core RBAC model): A core RBAC model
has the following components:
• V , O-p, o , and s (the set of users, roles, permis
sions, operations, objects, and subjects, respectively).
• A m CUxTl.i many-to-many assignment from users
to roles.
• CHxV, a many-to-many assignment from roles
to permissions.
• role_users, an one-to-many assignment from a role
r € 11 to its users, which have connections to it:
r o le _ u s e r s ( r ) - {ti e u I (u,r) 6 A u n )
• role p e rm issio n s, an one-to-many assignment from a
role r e 71 to its permissions:
role_permissions(r) = ịp € p Ị (r,p) e A fiv)
« subject juser, an one-to-one assignment from a subject
to its corresponding user.
subjed_user(3) = u € u that 3 is created by ti
• 3ubject_roles, an one-to-many assignment from a sub
ject to its roles.
subject_roles(s) = {r € K I
subject_user(3) € role_users(r)}
RBAC has two important properties stated in Definition
2.2 and Definition 2.3. Rote authorization property defines
that each role
T
owned by any subject
3
must also be owned

by the subject’s user. More importantly. Object access autho
rization says if user u can access the permission p = (op, o),
which we denote by |u, (op, o)J with p 6 p, op € O-p tưid
o e o , there exists a role r that r is in the list of roies
assigned to u and T can access p.
Definition 2.2 (Role authorization):
V j 6 5, Vr € subject_Tolts{s)
=> (subjcct_user(3),r) € A un
Definition 2.3 (ObjiCt access authorization):
[u,(op,o)J = 3p € p ,3 r € n : p = (op,o),p €
role_permÌ33Íons(r) A lí 6 rolc_uaer3 (r)
III. D e f i n i t i o n o f a s im p l e a b s t r a c t l a n g u a g e -
L r b a c
Each implementation of RBAC needs to be written by a
modem programming language like C++ or Java. However,
the syntax of these languages is too complex in the scope
of RBAC analysis since we can only take into account
three types of commands: assignments, operations which
access to system resources, and control flow statements.
As a result, we introduce in this section L r b a c . a simple
absưact language used for writing RBAC implementations,
to explain the theoretical aspects of our method. Figure 3
describes L rb a c syntax in BNF-style conventions:
s Statement
(1)
V-<E
Assignment
(2)
1 s,s
Sequencing

(3)
I op(o, {£})
Operation
(4)
if(E)S[S}
If-then-else
(5)
1 while (E) s
While loop
(6)
1 for ([{S(I)}|; [£Ị; [{5(i)}j)S
For loop
E
Expression
(1)
V
Variable
(2) 1 c
Constant
(3)
1 E ® E
Operation
Figure 3. L r b a c synti*
In Figure 3, ị ] denotes optional items, {} denotes repet
itive ones, and I means a choice. Assignment notation -<
in 5(t) can be arithmetic assignment (=, +=», -= , »=, /«,
%=, *=), shift assignment (<<=, » = , >>>=), or boolean
assignment (&=, I =). Similarly, operation notation ® in £(3)
can be arithmetic operation shift operation
(<<, >>, >>>), or boolean operation (1 ,4 , ==. !=, <, >,

<=. >=).
216
Since we can convert every prepositional formula into
an equivalent formula written in conjunctive norma] form
(CNF) by applying the double negative law, the De Morgan’s
laws, and the distributive law [4], each expression can
be rewritten to be a conjunction of clauses. However, in
S(4)(5)(e). if an expression contains more than one con
junction of clauses, we can separate these conjunctions by
attaching them to additional consecutive if-statements. For
example:
if (E & E ‘) s [5] ew^ rt if (B) {if (£ ') s (51}
while (E & E') s c™ ert while (E) {if (B ') 5}
for (i{5(1)}]; E s £•; |{S(«}]) s con^ rt
Therefore, we make a reasonable assumption that expres
sions in S(4)(5)(6) only consist of disjunctions of clauses.
Because our goal is to check the consistency of im
plementation with RBAC policies, we need to focus on
analyzing conditional policies, which is expressed by three
expressions of tf-Statement 5(4), While-Statement 5(5), and
For-Statement 5(6) in
L r b a c - Figure 4 shows their syntax
and AST forms.
If-Statemem
È
Expression
Then-Statement
[Eise-Statement]
&*)
-E

-s
L5
While-Statement Sti)
Ị-Expression ị-£
L
Body
For-Sutement
s*t
-[Initializers]
-Sin
- [Expression]
■E
- [Updaters]
■&n
l-Body Ls
Figure 4. AST form* of [f-S uierrent, W hile-Statement, and For-Stitem ent
According to our above assumption, the expressions of
If-Statement 5(4), While-Statement 5(5), and For-Statement
5(g) have syntax E = E \ E. In AST, it means that if a
node represents for a expression E = E l I J&2 I ••• Ỉ Ek, the
node will have k children and each child corresponds to a
sub-expression in the right-hand side.
IV. C h ec k in g ALGORITHM
We state in Algorithm 1 our primary contribution, an
algorithmic method to validate the conformance between
implementation and RBAC policies. For simplicity, our
algorithm does not work with multiprocessing systems; in
another words, there is at most one process (subject) created
by a user at any particular point of time. Before discussing
in detail, we introduce some notions and definitions used in

our algorithm:
• If a node n € A S T represents for a L r b a c ’s syntax,
we denote this relationship by c .
• Regardless of subjects created by users, each checking
process maintains a set Tuple of quadruple tuples
(u,r,op,o). Each tuple means user IX performs oper
ation op on object 0 under role r. Items of each tuple
will be shown as 0 if we do not know their values, or
as a variable if the variable holds the value, or as a
constant if the value is explicitly known.
• The values of a tuple t may be changed by assign
ments. If node n contains assignments, which are 5(1)
and £ (1)(J)(3 ) in L r b a c . that affects a tuple t, we
denote this event by Teplace(t,n). For example, if
we have t = (0,0, write, o) and node n contains
an assignment o—< in p u t.tx t, then replace(t, 71) =
(0,0, write, input.txt).
• For each tuple t = {u,r,op,o), we need to know
whether it violates the Role authorization (Definition
2.2) and Object access authorization (Definition 2.3)
of a RBAC policy or not. If t does not, we accept it,
otherwise t will be rejected. We formalize the accept
operation by the following formula:
i
(op, o) e V if u = 0
(r = 0 V (u ,r) 6 A im )
A |u, (op, o)J ift1^0
Our algorithm takes AST of implementation and RBAC
database as input parameters, and then returns the result
of checking process. The idea of the algorithm can be

described as follows. Fữst, we traverse all nodes of input
AST. Each time we find a node no that accesses to system
resources during the traversal, we initialize a new Tuple
and go backwards to update the Tuple via assignments and
conditional expressions. If we meet an assignment, every
tuple t € Tuple will be changed by replace operation. In the
case of visiting conditional expressions with k disjunctive
clauses, we clone k versions of each tuple t € Tuple and
then perform replace each version with its corresponding
disjunctive clause. After finishing going backwards started
from a node no, if there is any t € Tuple that we have
accept(t) = true, the node no conforms with DB. The
process continues until we successfully find a node no that
violates DB or wc reach the root of A S T . Our algorithm
is terminable since we traverse AST, which is a finite ưee.
V. A CASE STUDY OF OUR ALGORITHM
In this section, we illustrate our approach by a ease study
of processing invoices after buying items described in [5],
[6], Also having applied theứ approach to the scenario,
Hansen and Oleshchuk [2] showed an example of a RBAC
policy in Tabic I. We also use the policy in Table I to
demonstrate how our method proceeds.
Consider a simple uscr-define code-snippet and its cor
responding AST in Figure 5. The code-snippet contains
two if-statements. The first if-statement, which conforms to
RBAC policy described in Table I, aims to feature both Role
217
Algorithm 1: Consistency checking
Table I
RBAC POLICY OF PROCESSING INVOICES

Input : AST: AST'of source code
Input : D B: RBAC database
Output: Conformant or not
Data : n, no, n': A ST nodes
P rocedu re A ST T rav«r«al (AST, D B )
begin
forail n e A ST do
if n c 5(3) then
if -'isConformant(n) then
|_ return false
return true
end
Procadura iaConformant(no)
begin
n «— no
Tuple - {{0,0,no-op,no.o)}
repeat
If n c {5(1),£(1)(2)(3)} then
forall t € Tuple do
|_ t «- replace(t,n)
_ return
t f n e f i and parent(n) c S(4)(5)(6) then
forall t € Tuple do
forall n' 6 children(n) do
|_ Tuple*- Tuple u replace(t,n')
Tuple *— Tuple \ {i}
n «— go_backwards(n)
until n = AST.roof
foraU t € Tuple do
tf accept(t) then

L return true
return false
end
[
7;6
3:2; 1
u ■■ ■
n 'K
V
AJice
supervisor cleric
pi
Bob
officer
officer
pi. p2
Claire
clerk
supervisor p2. p3
Anthur
supervisor
Đúc
officer
V
o-p Ỡ
P1
record invoice
p2
verify
invoice

.
authorize
invoice
i f ( u se r -=• “Bob") o r ( r o le - - " o f f i c e r " )
r e c o r d (i n v o ic e )
v e r i f y ( i n v o i c e )
i f u s e r — * E lise *
a u t h o r iz e ( i n v o ic e )
Statement
If-Stateraenỉ
Expression
L user = “Bob”
L role — “officer”
- Then-Statement
t
record(invoice)
verify(invoice)
If-Statement
[
Expression
lu ser — "Elise"
Then-Statement
L authorize(invoice)
Sm
-Sm
- E<1>
- Eo I
- EiìI
- Sa>

Ls»
-E
L£b,
Li
t-Ẳi>
authorization and Object access authorization. The second
one violates the RBAC policy specification.
Our algorithm detects three statements that access to
system resources at node 7, 8 and 13. Starting from these
nodes, we create empty Tuple and go backwards to the root
of the input tree. At node 7, we have the following Tuple:
Figure 5. A c»ie Jtudy of our algorithm
checking procedure at node 8 in a similar way:
{(0,0,0,0}}
8~*6{(0>
01
v e r i fy , in v o ice)}
3£il{ (Bob, 0, ve rify, invoice), (0, o / ficer, ve rify, invoice)}
Also, we have accept((Bob,Q ,verify,invoice)) = true
and accept{(9,ofJ\C£T,verify,invoice)) = true. The
code-snippet still obviously conforms with its RBAC policy.
Consequently, we go to node 13 and obtain:
{(0,0,0,0)}
{(0,0, record, invoice)}
{(Bob, 0, record, invoice), (0, o ffice r, record, invoice)}
13; 12
{{0,0,0,0)}
{{0,0, authorize, invoice)}
Since accept((Bob, 0, record, invoice)) — true and
accept{(Q,ofỉicer,record,invoice)) = true, we do not

find any violation at node 7. Therefore, we continue the
l0&2; 1 {{Elise, 0, authorize, invoice)}
We concludc that the implementation does
not conform to its RBAC policy owing to
accept((Elise,<i, authorize, invoice)) = false.
218
V I. R e l a t e d w o r k
Since RBAC was first proposed by Ferraiolo and Kuhn
(7] and then improved by other literature [8], [9], [10], it
becomes an ongoing topic and attracts many researchers to
work on it. Li and Mao [11] introduces a method to design
and analyze administrative models of large RBAC systems.
For extremely large and distributed systems, Dekker et al.
[12] gives a RBAC model for administration. Kwon and
Moon [13] use semantic web ontology language (OWL) to
formalize and visualize RBAC policy constraints.
Also regarding confidentiality policies, Tschantz and
Wing [14] introduce a method to extract conditional policies
from source code. Unlike us, this work attempts to reveal
hidden policies from a given implementation. Although their
Whileio language is far from reality, their algorithm ĨS'
novel and effective. We intend to combine theừ method
with ours to attain a stronger one which can not only verify
predefined security policies but also discover hidden others
that a program obeys.
Conformance testing of RBAC policy and its imple
mentation has been studied in [2] and [3]. Hansen and
Oleshchuk [2] propose a solution that uses Linear Temporal
Language to express policy and PROMELA language of
model-checking system SPIN to represent for implementa

tions. Recently, Ammar et al. [3] also addresses the problem
of conformance testing for Access Control Implementation
under Test (ACUT) in Temporal Roles-Based Access Con
trol (TRBAC) systems. Not only approaching theoretical
aspects of the problem, our work differs from them in that
we analyze AST of source code to check the consistency.
Our method is therefore suitable for implementing in actual
systems, which often provide only source code of imple
mentations for static analyzers to investigate.
V II. C o n c l u s i o n a n d F u t u r e w o r k
Designing and implementing software systems concerning
security policy is always a difficult task, particularly with
complex systems. In this paper, we propose an approach to
check the compliance between security policy specifications
of a system with its implementation. RBAC, a new and effi
cient language based on role of users, is used to specify user
permissions of security policy. Wc demonstrate our method
through a specific case study. Our algorithm, however,
currently ignores some complex but practical features of
normal programming languages such as method invocations,
exceptions, polymorphism, and parallelism. Wc plan to work
on these points and implement this algorithm in the Eclipse
platform to use the CDT, a plugin enabling to automatically
generate c source code as an AST.
A c k n o w l e d g m e n t
This work is (partly) supported by the research project No.
QC.09.01 granted by Vietnam National University, Hanoi.
R e f e r e n c e s
[1] D. F. Fenaiolo, R. D. Kuhn, and R. Chandramouli, Role-
Based Access Control, Second Edition. Norwood, MA, USA:

Artech House, Inc., 2007.
[2] F. Hansen and V. Oleshchuk, “Conformance Checking of
RBAC Policy and its Implementation,” in Proceedings o f the
First Information Security Practice and Experience Confer
ence (ISPEC 2005). Springer, 2005. pp. 144-155.
[3] M. Ammar, A. Ghafoor, and A. Mathur, “Conformance Test
ing of Temporal Role-Based Access Control Systems," IEEE
Transactions on Dependable and Secure Computing, 2008.
[4] H. B. Enderton, A Mathemalical introduction to Logic, Sec
ond Edition. Academic Press, 2000.
[5] D. D. Clark and D. R. Wilson, “A Comparison of Commercial
and Military Computer Security Policies," in 1987 IEEE
Symposium on Security and Privacy. IEEE Computer Society
Press, 1987, pp. 184-194.
[6] M. J. Nash and K. R. Poland, “Some conundrums concerning
separation of duty," IEEE Symposium on Research in Security
and Privacy, pp. 201-209, 1990.
[7] D. Ferraiolo and R. Kuhn, “Role-Based Access Contfol,” in
In 15th NỈST-NCSC National Computer Security Conference,
1992. pp. 554-563.
[8] R. S. Sandhu, R. s. s, H. Y, E. J. Coyne, H. L. Feinstein,
and c . E. Youman, “Role-Based Access Control: A Multi-
DimensionaJ View,” in Proceedings o f the 10th Conference
on Computer Security Applications, 1994, pp. 54-62.
[9] R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and c. E. Youman,
“Role-Based Access Control Models,” Computer, vol. 29.
no. 2, pp. 3S-47, 1996.
[10] R. Sandhu. D. Ferraiolo, and R. Kuhn, "The NIST model
for role-based access control: towards a unified standard," in
RẼAC '00: Proceedings o f the fifth ACM workshop on Role-

based access control. New York, NY, USA: ACM, 2000,
pp. 47-63.
{11] N. Li and z. Mao, “Administration in Role-Based Access
Control," in ASIACCS ‘07: Proceedings o f the 2nd ACM
symposium on Information, computer and communications
security. New York, NY, USA: ACM, 2007, pp. 127-138.
[12] M. Dekker, J. Crampton, and s. Etalie, “RBAC administration
in distributed systems,” in SACMAT '08: Proceedings of
the I3lh ACM symposium on Access control models and
technologies. New York. NY, USA: ACM, 2008, pp. 93-102.
[13] I. Kwon and C J. Moon, “Visual modeling and formal
specification of constraints of RBAC using semantic web
technology,” Knowledge-Based Systems, vol. 20, no. 4, pp.
350-356“ 2007.
[14] M. c . Tschantz and J. M. Wing, "Extracting Conditional Con
fidentiality Policies," in SEFM '08: Proceedings o f the 2008
Sixth IEEE International Conference on Software Engineering
and Formal Methods, 2008, pp. 107-116.
219
ĐẠI HỌC QƯÓC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Phạm Mạnh H ùog
NGHIÊN CỨU ĐẶC TẢ UML SECURITY
KH O Á L U ẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY
Ngành: C ôn g nghệ thông tin
Cán bộ hướng dẫn: TS. Trương Ninh Thuận
HÀ NỘI-2010
ĐẠI HỌC QUÓC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Nguyễn Thị Thanh Thủy

NGHIÊN CỨU AN NINH DỊCH v ụ WEB
KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHỈNH QUY
Ngành: Công nghệ thông tin
Cán bộ hirómg dẫn: Tiển sỹ Trương Ninh Thuận
SUMMARY
Project name: V erification o f software security policy
Project code: QC.09.01
Duration: From 05/2009 to 05/2010
Management Organization: Vietnam National U niversity
Performing O rg an iza tio n : College o f Technology
Project leader: Truong Ninh Thuan, Dr Sex: Male
Birth year: 1977
Training speciality: Inform ation Technology
Title: Dr
Job. title: Lecturer
Office: Faculty o f Inform ation Technology, C ollege o f Technology, VNƯ.
Address: P309, B uilding E3, 144 Xuan Thuy, Cau Giay, Hanoi
Tel: (04) 7549016 Fax: (04) 7680460
Email: thuantn@ vnu.edu.vn
Project team members:
No
Full Name
Title, Organization
1
Truong Ninh Thuan
Phd Department o f Software Engineering,
College of Technology
2
Nguyen Viet Ha
Phd Department o f Software Engineering,

College of Technology
3
Vu Quang Dung MA
Department o f Software Engineering,
College of Technology
4
Truong Anh Hoang
Phd Department o f Software Engineering,
College o f Technology
Training results:
- 02 bachelor thesis.
1. Nguyễn Thị Thanh Thủy, Nghiên cứu về an ninh dịch vụ web, Trường Đại học
Cong nghệ, ĐHQGHN, 2010.
2. Nguyễn Mạnh Hùng, Nghiên cứu đặc tả UML security, Trường Đại học Công
nghệ, ĐHQGHN, 2010.
Scientific and technological results
Content and research results summary:
Security policy is a critical property in software applications which require high levels of
safety and security. It has to be clearly specified in requirement documents and its
implementation must be conformed to the specification. In this paper, we propose an
approach to check if the implementation is in accordance with its security policy
specification. We use the Abstract Syntax Tree (AST), another manner o f expressing the
program, to analyze the source code and specify user permission policy in software
systems by Role-Based Access Control (RBAC).
Publish papers by the project:
- 01 papers in international conferences:
Tuan-Hung Pham, Ninh-Thuan Truong, Viet-Ha Nguyen. Analyzing RBAC Security
Policy o f Implementation Using AST. In proceeding of International Conference on
Knowledge and Systems Engineering (KSE 2009). Hanoi, Vietnam, pp. 215-219, 2009.
Other results

Trainning several official staffs with knowledges on software modelling and
verification, increasing the quality of teaching and research at College o f Technology.
ivẠị H Ọ C Q L Ó C G iA H A N Ồ I C Ộ N G H Ò A X À H Ộ I C H I N G H Ĩ A V l í i ĩ \ . \ \ Ị
TR;"Ờ N G đ ạ i h ọ c c ó n g n g h ệ độc lập - Tự do - Hạnh phúc
ỹ - o ủ o ■ - - - - - •• O Ũ O -"- " -
S ó : H Đ - N C K H
Hù Xội. ngủ} - íl ' ỉiiủtvỉ •him '" ‘/V
HỢP ĐỎNG THỤC HIỆN ĐẺ TÀI NGHIỆN c ứ u KHOA HỌC
C Ả P Đ Ạ I H Ọ C Q U Ố C G IA H À N Ộ I NĂM 2009
vii' Ii‘ U::; .ĩù ỉiỉ 7n t/.'ir: . lỉõ n ỵ : i r j D a i h tK O'.I'K. M'ii H j 1 r"J" h ri1’1 '»'.v u<\ 1*‘
/«. c ’&' /i <>ỉ lỉ ú - i ỵ I IJ l ủ m yii.il ctiư D ụ i h ọ c O it iK ví/li //ứ A/ I
c (I : /í/17! ir t n m ^ ijy. ỉrin n ii! j ' j i h ‘K ìlk iiìh viừn.
■ 1 .ill i l l I h ô n g h iiti UJ ịịf~ i T B -K ÌK ' V' ir Ặ i y 1*3 í/iú iì‘ỉ ổ Ihĩtn y i t i v LÍU! < iuu ii f • .\v V
//;■' »v t'/L\ nluỌ iìi VII v j \.in liiĩít ẲÝ ìn Jilt'll k h o a hm . (V c õ n ỵ n ỵ h ii IIÚIII 2 o i1'/
- .Ui í ;r t/V I‘in 'i!iỉ ‘1\!!!ÌỮIÌ c ú n ■- ÍKÍ ;.v lới ilà iltiơ c />//c iiuv ự í.
<. hull" tôi ưõnv
B ú' uiao nhiệm \ ụ (gọi lá hên A): Trưònu Đại học CỏnỊỉ nyhệ - DliQG ĩIà .Nội
!Xti -liệu [ã: P G S 1 s NtỊtiyễn N g ọc B inh
IUÍC vụ: Hiệu trưưtm
Bén nhận nhiệm MỊ (gợi ià bên B)
ỎHtí: TS Trưortg Ninh Thuận
Đ ưp VỊ cò n u tac: Khoa c ỏ n ư iVihẽ T hóna tin T ruởna Dại học CóIiii nyhệ
k ' hưp clónu thục hiện dể tai ntíhiẽn cưu khoa học cap Đại hục Ụuỏc iíia Ha Nội"
ỉ On dô lái "K iêm c h ứ n g d ặ c ta SecuritẠ Policy".
M à sỏ ụ c 09 .01.
V oi nh ữn e dièu khoan thoa thuận nlur sau:
Ư iíu 1: li On B chịu trách nhiOm ió chu c trién khai ihực hiện cac nội dunu niìhicn '.•.ru . ’.'.a ■
tai theo dũnu ticn dộ thực hiện dù viiui'j k\ irony đẽ c ươn li nuhiòn cưu dà được phò úuy-i
i)iCu 2: lỉcn 15 bao cáo kẽt qua thục hiện dẻ tái vã uiao nộp các san phàm cua dô Ị.ii
\ ihco duiTi các ụ LU định hiên hanh cua Đại học Ọ u òc uia Ha Nội và cua rrưóni: Dai ÍH

Cònii niihc U'Ư«C nuav. 2 0 ’06-Zo iii. bao iiòm.
111 b;u> cao in tại k'. \õu hi‘»i n>_ih.ị ehuvén nuánh quóc lõ
u : klióa luận UU nuhiOp.
I õnLi quan \õ J c lái kcm :hc.i lì le diện tư (MỘI ban hãnii liẻnn Việt, mỏ! han hur.'j
ucnu \n h Hiahliuhi. mủi ran dái khoanu 4 0 0 úr ircn một tranii *_ỉiãV khó \4. imv.
i im e N ew Rom an, cữ chù i 3pi. cách do n i dan: NỘI ùun-i: ỉ ỏm tá! m ục 1 1 p!i.íơivj
pháp \ ã nội duna nsihiẽn két qua đại dưự c. dành 'iiủ ý nghĩa và tac đỏnu khua
hue cônu nahệ cua các két I.ỊIUI đại được eũna như cua V ICC thực hiện dê tai)