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

Mỗi người sử dụng hệ th ốn g sẽ được gán m ột vai trò, mỗi vai trò có quyền tru y cập đến các đối tượng và các chức nẫng nào của hệ th ố n g ph ải tu â n theo các đặc tả về an ninh củ a

ĐẠ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ố: Q C 0 9 0 1

C h ủ n h iệ m đ ề tài: T S T r ư ơ n g N in h T h u ậ 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 P hần mở đ ầ u 1

1.1 D anh sách những người th a m gia thực hiện đề tài 1

1.2 Báo cáo đề t à i 1

2 P h ần nội d un g c h í n h 3

2.1 Đ ặt vấn đề 3

2.2 Tổng q u an các vấn đề nghiên c ứ u 4

2.3 Dề x u ấ t giải p há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

1 Phần mở đầu

1.1 Danh sách những người tham gia thực hiện đề tài

• Đ ịa chỉ liên hệ: P309 n h à E3, 144 X uân Thủy, Cầu Giấy, H à Nội

• Em ail: 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 á n g 0 6 /2 0 ^ 0

• N guyễn T h ị T h a n h Thủy, N ghiên cứu về an ninh dịch vụ web, Trường

ĐH Công nghệ, 2010

• P h ạm M ạnh H ùng, Nghiên cứu đặc tả UML security, Trường DH Công nghệ, 2010

K ế t q u ả k h o a h ọ c v à c ô n g n g h ệ :

Tóm tắt nội dung và kết quả nghiên cứu:

Sự p h á t triển n h an h chóng củ a p h ần mềm tro n g tấ t cà các lĩnh vực của cuộc sống và những lợi ích m à nó m ang lại cho con người đ ã được khảng định T uy 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 q uả khó lường nếu x u ấ t hiện các lỗi tro n g 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ề C N T T cần p hải có những giải p h á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 tru y cập vào hệ th ốn g 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 tru y cập vào tà i nguyên hệ th ố n g m à không quan tâm đến chi tiế t việc cài đ ặ t Mỗi người sử dụng hệ th ốn g sẽ được gán m ột vai trò, mỗi vai trò có quyền tru y cập đến các đối tượng và các chức nẫng nào của

hệ th ố n g 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 tru n g nghiên cứu để đóng góp các giải p h áp khác n hằm hạn chế các lỗi của chương trìn h liên quan đến security policy, các giải p h áp này bao gồm việc tích hợp các ràn g buộc liên quan đến security policy và hệ th ốn g phần m ềm và làm th ế nào để kiểm chứng được đặc tả và thự c th i của hệ thống p h ầ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-H ung P h am , N inh-T huan Truong, V iet-H a Nguyen Analyzing

R B A C Security Policy o f Im plem entation Using A S T In proceeding of

In tern atio n al Conference on Knowledge and System s E ngineering (KSE 2009) Hanoi, V ietnam , pp 215-219, 2009

K ế t q u ả t ă n g c ư ờ n g t i ề m lự c c h o đ ơ n vị: Đào tạo được m ột số cán

bộ có hiểu biết về kiểm chứng p hần mềm, có k h ả 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 tr a các tín h ch ất về an ninh hệ th ốn g và về sự tin cậy của phần mềm

2

2 Phần nội dung chính

Sự p h á t triển n h an h 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ó m ang lại cho con người đ ã được k h ẳng định Tuy nhiên, bên cạn h n hữ ng lợi ích to lớn này, các hệ thống p h ần m ềm cũng

có th ể gây ra n hữ ng hậu q u ả khó lường nếu x u ấ t hiện các lỗi tro n g 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

q u ả để p h á t hiện các lỗi p h ầ n m ềm trước khi đ ư a vào sử dụ ng tro n g thực tế.Trong p h á t triể n p h ầ n mềm, đặc tả có nhiệm vụ đư a ra các mô tả và ràn g buộc b an đ ầ u cho h ệ thống phần mềm, giúp những người p h á t triển hiểu được chính xác các chức năng, nhiệm vụ, h o ạt động củ a hệ thống Lập trìn h viên, dự a trê n n hữ ng tài liệu đặc tả này, sẽ xây dựng hệ th ố n g phần

m ềm bằng các ngôn ngữ lậ p trìn h khác nhau T u y nhiên, chương trìn h sau khi xây dựng có th ể sẽ không th ỏ a m ãn m ột số ràn g buộc tro n g các tài liệu đặc tả

Điều khiển tru y cập tro n g 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 tru y 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 tru y cập là bảo to à n tín h bảo m ậ t và toàn vẹn củ a hệ thống Trong các kỹ

th u ậ t thường hay được sử dụng để điều khiển tru y cập, DAC (D iscretionary Access C ontrol), M AC (M an d ato ry Access C ontrol) và R B A C (Role-Based Access C ontrol) là các kỹ th u ậ t mới n h ất và hiệu q u ả n h ấ t tro n g các ứng

dụ ng thương m ại và hệ th ố n g qu ân sự, dựa trên tiềm năng về cấp ph ép quyền tru y cập, giảm chi phí q u ản trị và phòng ngừa các lỗi xảy ra tro n g các hệ thống lớn [4] Trong đề tà i này, chúng tôi chọn E B A C là ngôn ngữ m ô tả cơ chế an ninh cho h ệ thống

Khi m ột hệ th ố n g p h ầ 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 th i cù ng với các yêu cầu khác của hệ thống T uy nhiên, việc đặc tả và thự c th i hệ th ố n g có thể được thực hiện bời nhữ ng người khác nhau và tro ng 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 đ ú n g đặc t ả an ninh của hệ thống

Vấn đề tu â n th e o giữa th iế t kế RBAC và thự c thi hệ th ố n g đ ã được xem

x ét về m ặ t lý th u y ế t tro n g các nghiên cứu của H ansen và O leshchuk [5| và Anrưnar et al [1], T uy nhiên, các nghiên cứu n ày vẫn chưa xem x ét kiểm

tr a xem việc thự c th i chương trìn h 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 tr a sự phù hợp vởi đặc tả RBAC của m ã nguồn chương trìn h bằng cách phân tích cây cú p h áp trừ u tượng A S T {A bstract S y n tax Tree)

2.2 Tổng quan các vấn đề nghiên cứu

TVong m ột m ô hình điều khiển tru y 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ìn h này gọi

là subjects tro ng RBA C Bởi vì những tiến trìn h này thực hiện th a y 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à 'tru n 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 (perm ission) 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 th a o tác nào của người sử dụng

Q uan hệ giữa các th à n h 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 (perm ission), th ao tác (operation), đối tượng tác động (object)

• -Ann c u X 71, quan hệ nhiều-nhiều từ users đến roles.

• A n v Q 71 X 'P, quan hệ nhiều-nhiều từ roles đến perm issions.

• r o le _ u s e r s , quan hệ m ột-nhiều từ role r € 71 dến users có kết nối:

ro le_ u se rs(r) = {u 6 u I (u, r) € Auv.)

• r o le _ p e r m is s iơ n s , quan hệ m ột-nhiều từ vai trò r e 71 đến perm is­ sions:

4

r o le _ p e r m is s iơ n s (r ) = {p € V I (r,p ) € A n p }

• s u b je d _ u s e r , quan hệ m ột nhiều từ subject dến user tương ứng.

s u b je c t_ u s e r (s ) = u € U , s được tạo bởi u

• s u b je ă _ r o le s , quan hệ m ộ t nhiều từ subject đến roles:

T ừ khi RBAC lần đ ầu được đề x u ất bởi các tác giả Ferraiolo và K uhn [3]

và cải tiến bởi các nghiên cứu [8, 7, 6], nó đ ã trỏ th à n h m ột ngôn ngữ được

sử dụng rộng rãi tro n g 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, T schantz 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ìn h 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 th i phần mềm

Sự kiểm tra tu â n th eo giữa đặc tả RBA C và phần thực th i cũng đ ã được nghiên cứu tro ng các bài báo [5] và [1] H ansen and O leshchuk [5] đề x u ất một giải p h áp sử dụn g L inear Tem poral Language để biểu diễn các điều kiện bảo

m ật và ngôn ngữ PR O M E L A để m inh họa phần thực thi G ần đây, A m m ar

e t al [1] cũng hướng đến kiểm chứng vấn đề này những lại sử dụ ng kỹ th u ậ t

T est phần mềm N ghiê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 tr a sự tu â n theo giữa thự c th i và đặc tả RBAC

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 R B A C cần phải được viết bởi m ột ngôn ngữ lập trìn h 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ìn h

đó 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ỉ q u a n tâ m tới ba tậ p lệnh sau: các lệnh gán, các lệnh m à có tru y cập tới tà i nguyên hệ thống, và các lệnh rẽ n há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ú p h áp củ a L r b a c dưới dạng biểu diễn BNF:

Trong hình 2, [ ] chỉ các phần tử có th ể có hoặc không, {} chỉ các p hần tử

x u ấ t hiện nhiều lần , và I chỉ các lựa chọn P h é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

b it (<=, >=, » = ) , hoặc các phép gán logic (Ề=, l=) T ương tự vậy, phép ©

tro n g E (3) có th ể là các th a o tá c toán học (+, *, / , '/„ ), các lệnh dịchchuyển b it (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 à n h công thức dưới dạng chuẩn hội (C N F) bằng cách áp dụng các lu ật hai lần phủ định, luật De

M organ, và lu ậ t p h ân phối [2], mọi biểu thứ c có th ể được viết lại th à n h dạng hội của các th à n h phần Nếu biểu thức tron g 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 à n h các lệnh if kế tiếp nhau Ví dụ:

i f ( E k E ) s [51 con” ri ự (E ) { i f ( E ' ) s [5]}

6

H ình 3: D ạng A ST củ a lệnh If, lệnh W hile, và lệnh For

T heo giả định đ ã nói ỏ trên, các biểu thứ c trong-lệnh If 5(4), lệnh W hile

•5(5), và lệnh For 5(6) có cú p há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 t o á n k iể m c h ứ n g

T h u ậ t toán 1 trìn h bày m ột phương p háp để kiểm chứng sự n h ấ t quán giữa cài đ ặ t và đặc t ả RBAC Để cho đơn giản, th u ậ 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 n h ất một tiến trìn h (đố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 th u ậ 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

• K hô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

tr a ta sẽ duy trì m ột tậ p hợp Tuple củ a các bộ bốn p h ầ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 à n h phần của mỗi bộ sẽ được thể hiện là

0 nếu n h ư 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ố

A lg o r it h m 1: K iểm tr a sự thống n h ất giữa cài đ ặ t và đặc tả RBAC

I n p u t : A S T : A ST của m ã nguồn

I n p u t : D B : Cơ sở dử liệu RBAC

O u t p u t : Đ ặc t ả và cài đ ậ t có thống n h ấ t với nhau

Tuple <— Tuple \ {i}

Các giá trị của m ộ t bộ bốn phần tử t có thể được th a y đổ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) tro n g 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 repla ce(t, n) Ví

dụ, nếu t a có í = (Q, Q, w r ite ,o) và n ú t n chứa lệnh gán o —< in p u t.tx t

th ì r e p la c e (t} n) — (0 ,0 , w rite, in p u t.tx t).

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ò tro n g Đ ịnh nghĩa 2.2 và quyền tru y 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 n h ận (accept) nó, ngược lại t sẽ bị loại bỏ T a hình thức hóa accept n hư sau:

a c c e p t^ U y T ơ 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

T h u ậ 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 q u ả của việc kiểm tra Ý tưởng của th u ậ t toán như sau: Đầu tiên, t a 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, t a tạ o m ột Tuple mới và quay ngược trỏ lại để cập n h ật Tuple q u a các lệnh gán và các biểu th ứ c điều kiện Nếu

t a gặp m ột lệnh gán, mỗi bộ í € Tuple sẽ bị thay đổi bởi th ao 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 x u ấ t p h á t từ nút

n 0 xong, nếu có b ấ t kỳ t € Tuple nào m à có accept(t) = tr u e thì nút no sẽ

n h ấ t quán với D B Q uá trìn h 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 t a đ ã kiểm tr a tới nú t gốc của A S T T h u ậ t toán này đảm bảo tín h dừng vì nó duyệt q u a A ST là m ột cây có hữ u hạn nút

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 à n h đầ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 th i 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 tru y cập người dùng Khi kiểm chứng,

th ay vì p hân tích các lệnh m â nguồn, chúng tôi thực hiện p h ân tích cây A ST của nó.

Hiện tạ i chúng tôi chỉ mới đề x u ất th u ậ 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

th u ậ t to án này trê n Eclipse platform để sử dụng CD T, m ột plugin có khả năng sinh tự động m ã nguồn c th à n h m ột cây cú p h áp trừ u tượng AST

AO

Tài liêu tham khảo

[1] M A m m ar, A G hafoor, and A M athur Conform ance Testing of Tempo­

ral Role-Based Access C ontrol System s IE E E Transactions on Depend­

[2] H B E nderton A M athem atical Introduction to Logic, Second Edition

Academ ic Press, 2000

[3] D Ferraiolo an d R K uhn Role-Based Access Control In In 15th N IS T -

N C S C N ational C om puter Security Conference, pages 554-563, 1992.

[4] D F Ferraiolo, R D K uhn, and R C handram ouli Role-Based Access

Control, Second Edition A rtech House, Inc., Norwood, MA, USA, 2007.

[5] F H ansen an d V Oleshchuk C onform ance Checking of RBAC Policy

and its Im plem entation In Proceedings o f the F irst In form a tio n Secu­

rity Practice and Experience Conference (IS P E C 2005), pages 144-155

Springer, 2005

[6] R Sandhu, D Ferraiolo, an d R K uhn T h e N IST m odel for role-based

access control: tow ards a unified stan d ard In R B A C ’00: Proceedings o f

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 C ontrol M odels Computer, 29(2):38-47, 1996.

[81 R S S andhu, R s s , H Y, E J Coyne, H L Feinstein, and c E Youman Role-Based Access C ontrol: A M ulti-D im ensional View In

Proceedings o f the 10th Conference on C om puter Security Applications,

pages 54-62, 1994

[9] M c Tschantz and J M Wing E x tractin g C onditional C onfidentiality

Policies In S E F M ’08: Proceedings o f the 2008 Sixth IE E E International

Conference on Software Engineering and Formal M ethods, pages 107-116,

2008

11

P H Ụ L Ụ C

P h ụ lục gồm có:

• 01 báo cáo tro n g hội nghị K S E ’09

• B ản sao Đề cương và Hợp đồng thực hiện đề tài nghiên cứu đ ã được phê duyệt

• P hiếu tó m t ắ t kết q u ả nghiên cứu của đề tài bằng tiếng A nh

• Phiếu đăng ký kết q uả 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

T uan-H ung P ham , N inh-T huan T ruong, V iet-H a N guyen

C ollege o f T echnology

V ietnam N ational U niversity

144 X uan Thuy, H anoi, V ietnam

Em ail: {pham tuanhung, thuantn, h anv}@ vnu ed u 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 o f 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 o f the security policy is enforced by strong

mechanisms There are organized methodologies and risk

assessment strategies to assure the completeness o f 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 o f 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 r b a c - The language only fo­ cuses on RBAC’s features and ignores other commands

o f normal program m ing languages Based on Lr 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 C h ecking R B A C Policy U sing AST o f Im plem 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 im plem entation 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.

II R o l e - B a s e d A c c e s s C o n 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 ,o p , 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 C U x T l i many-to-many assignment from users

to roles.

• C H x V, 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 l e _ u s e r s ( r ) - { t i e u I ( u , r ) 6 A u n )

• role p e r m is s io n s , an one-to-many assignment from a

role r e 71 to its permissions:

role_perm issions(r) = ịp € p Ị (r,p) e A fiv )

« subject ju s e r , an one-to-one assignment from a subject

to its corresponding user.

su b jed _ u ser(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 D efinition 2.3 R ote authorization property defines

that each role Towned 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):

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 r b a c syntax in BNF-style conventions:

(6) 1 fo r ([{S(I)}|; [£Ị; [{5(i)}j)S For loop

in 5(t) can be arithmetic assignment (=, +=», -= , »=, /« ,

%=, *=), shift assignment (<<=, » = , >>>=), or boolean assignment (&=, I =) Similarly, operation notation ® in £ ( 3 )

(<<, >>, >>>), 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 i f (B ) { if ( £ ') s (51}

while (E & E ') s c™ ert while (E ) { i f (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.

Figure 4 A ST form* o f [f-S u ie rren t, W hile-Statem ent, a n d 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 e c 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 o f quadruple tuples (u ,r,o p ,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, w rite, o) and node n contains

an assignment o —< in p u t.tx t, then rep la ce(t, 71) =

(0,0, w rite, in p u t.tx t).

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

(r = 0 V ( u ,r ) 6 A im )

A |u , (op, o)J i f t 1 ^ 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 D B The

process continues until we successfully find a node no that violates D B 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