5.3.1. Xây dựng chương trình chính
Chương trình chính viết trên Eclipse với ngôn ngữ Java. Do đây là bài toán rất nhỏ nên chỉ thao tác với hai file chính trong Project VisitorAST:
• “FindAExpressionVisitor.Java” (Thực hiện việc visitor các Expression
trong mã nguồn)
• “GetProject.Java” (Thực hiện hầu hết các thao tác xử lý và chạy chương trình).
Để thực hiện được thuật toán cần phải thực hiện rất nhiều bước.
Bước 1: Xác định được Project cần kiểm tra. Sau đó, mới bắt đầu thực hiện việc xử lý với Project đó
Bước 2: Duyệt một node trong các thành phần của cây. Với công cụ CDT, Eclipse
cung cấp một thành phần là DOM AST nhưng vấn đề quan trọng là phải nắm bắt được và thực hiện được việc duyệt được AST. Công cụ này cung cấp rất nhiều API để có thể thực hiện việc duyệt cây này.
Ví dụ để duyệt các Expression : shouldVisitExpressions = true ;
và hàm override hàm visit của nó
@Override
publicint visit(IASTExpression myExpression)
Tất cả những công việc này chúng tôi sẽ triển khai ở một file chứa class riêng để thực hiện. Công việc thực hiện ở file “GetProject.Java” chỉ là gọi các đối tượng của class này và thực hiện câu lệnh accept để bắt đầu tiến hành duyệt các Expression từ trên xuống trong file mã nguồn.
Bước 3: Thực hiện so sánh các Expression này với các Expression của các
Statement đang xét (ví dụ: ifStatement, whileStatement …).
Vì có nhiều Statement cần xét nên cần xây dựng một phương thức thể hiện tính đa hình của ngôn ngữ lập trình hướng đối tượng.
checkRBAC(ExpressionFunction, object, functionCall)
Phương thức này xử lý các trường hợp của Statement và cho kết quả là true hay
false. Kết quả trả về này rất quan trọng trong quá trình kiểm tra các điều kiện của mã nguồn tương ứng với các mô hình RBAC0.
Để hiển thị được kết quả sau khi kiểm tra có phương thức:
treatFunction(functionName, functionCall)
Phương thức này sẽ hiển thị các dòng thông báo sau khi kiểm tra thông báo lỗi cũng thấy rất rõ kết quả.
5.3.2. Xây dựng chương trình kiểm tra:
Chương trình kiểm tra khá đơn giản là một Project C/C++ tên RBACTest chứa file
RBACTest.CPP. File này có nhiệm vụ xây dựng một chương trình thể hiện được mô hình
RBAC0 với các biểu thức điều kiện và các hàm tác động đến “dữ liệu nhạy cảm” như đã quy định sẵn trong chương trình chính. Với mục đích chỉ thể hiện về mặt công nghệ nên mã nguồn được xây dựng trước (hard-code) nếu để phát triển lên một cấp cao hơn trong tương lai phải thực hiện với những đoạn mã nguồn không được quy định sẵn và được phát triển với hầu hết các mã nguồn đưa vào.
Chương trình kiểm tra nhất thiết phải là “runtime-EclipseApplication” để có thể chạy được chương trình. Với đầu vào là Project RBACTest. Giao diện của chương trình Test như sau:
Hình 5.3: Giao diện chương trình Test
Chạy chương trình Test
Với giao diện này khi chạy, sẽ có kết quả hiển thị ở màn hình console của chương trình chính. Khi chạy thành công sẽ hiển thị thông báo như sau:
Và kết quả nhận được ở chương trình chính như sau:
5.4. Kiểm thử chương trình5.4.1. Nội dung kiểm thử 5.4.1. Nội dung kiểm thử
Chương trình sẽ chạy thử với các yêu cầu kiểm tra khác nhau. Với input (đầu vào): một file RBAC.TXT được cấu trúc theo mô hình RBAC0.
File RBAC.TXT có dạng như sau:
User Role Permission
ThanhNV Root Write (“RBAC.TXT”)
TanNV User Read (“PUBLIC.TXT”)
TrungND User Write (“DB.TXT”)
HungNT Root Remove (“RBAC.TXT”)
Và mã nguồn C/C++ được viết theo mô hình mà file RBAC.TXT đã cung cấp. Mã nguồn cụ thể hóa vấn đề role là root sẽ có permissionWrite (“RBAC.TXT”) và điều cần làm là đối chiếu với file RBAC.TXT (như trên) để đưa ra output (đầu ra) để so sánh với output mong muốn đạt được.
1. Với biểu thức điều kiện đơn:
• Trường hợp lệnh write: Nếu nhập role là user và có quyền Write (“RBAC.TXT”) thì output mong muốn là lỗi. Và có thông báo lỗi cụ thể.
Hình 5.6(a): kiểm tra với lệnh write(có lỗi)
Dữ liệu nhập vào
Output mong muốn:
Có lỗi
Output chương trình
Còn nếu role là root mà permission là write (“RBAC.TXT”) thì không có lỗi xảy ra và output mong muốn là OK.
Hình 5.6(b) : kiểm tra với lệnh write ( không có lỗi)
Dữ liệu nhập vào
Output mong muốn:
Thỏa mãn
Output chương trình
• Trường hợp với lệnh remove: đây là xóa dữ liệu, việc Test cũng như với lệnh write.
Với mong muốn output là OK.
Hình 5.6(c) : kiểm tra với lệnh remove( không có lỗi)
Dữ liệu nhập vào
Output mong muốn:
Thỏa mãn
Output chương trình
Với mong muốn output là có lỗi:
Hình 5.6(d) : kiểm tra với lệnh remove(có lỗi)
Dữ liệu nhập vào
Output mong muốn:
Có thông báo lỗi
Output chương trình
2. Với biểu thức điều kiện lồng nhau:
• Trường hợp lệnh write: output mong muốn là lỗi.
Hình 5.7(a): kiểm tra với lệnh write(có lỗi)
Dữ liệu nhập vào
Output mong muốn:
Có lỗi
Output chương trình
Nếu output mong muốn là OK.
Hình 5.7(b) : kiểm tra với lệnh write ( không có lỗi)
• Trường hợp với lệnh remove: đây là lệnh xóa dữ liệu, việc Test cũng như với lệnh write.
Dữ liệu nhập vào
Output mong muốn:
Thỏa mãn
Output chương trình
Với mong muốn output là OK.
Hình 5.7(c) : kiểm tra với lệnh remove( không có lỗi)
Dữ liệu nhập vào
Output mong muốn:
Thỏa mãn
Output chương trình
Với mong muốn output là có lỗi:
Hình 5.7(d) : kiểm tra chương trình với lệnh remove(có lỗi)
5.4.2. Kết quả
Chương trình đã chạy thử và cho kết quả tốt. Khi Test với nhiều input khác nhau, chương trình đã chạy đúng và cho ra output đúng theo thuật toán.
Chương trình đã Test tất cả các trường hợp được mô hình RBAC0 mô tả gồm: 1. Trường hợp chỉ có một biểu thức điều kiện trực tiếp.
2. Trường hợp có nhiều biểu thức điều kiện lồng nhau.
3. Test với các lệnh ảnh hưởng trực tiếp đến hệ thống gồm write, remove … Tuy nhiên, nhược điểm lớn nhất của chương trình là giao diện chưa thân thiện. Kết quả chủ yếu chạy trên màn hình console.
Dữ liệu nhập vào
Output mong muốn:
Có lỗi
Output chương trình
Tuy đáp ứng được về mặt thuật toán nhưng chương trình cũng mới dừng lại ở việc “hard-code” và kiểm chứng với mô hình RBAC0 chưa mở rộng với các mô hình phức tạp hơn.
CHƯƠNG 6. KẾT LUẬN
“Kiểm chứng cơ chế bảo mật dựa trên AST” là đề tài nghiên cứu mới. Đã có rất nhiều cơ chế bảo mật được phát triển với những ưu điểm và nhược điểm riêng. Trong các cơ chế bảo mật đáng quan tâm thì nổi bật nhất là RBAC (điều khiển truy cập dựa trên vai trò). RBAC là một mô hình điều khiển truy cập tối ưu, có thể quản lý người dùng và truy cập của họ một cách khoa học nhằm hạn chế tối đa những xâm phạm bất hợp pháp vào tài nguyên của hệ thống. Dựa trên các mô hình của RBAC, cụ thể là RBAC0 đề tài đã xây dựng bài toán kiểm chứng dựa trên cây cú pháp trừu tượng (AST).
Sau khi hoàn thành, khóa luận đã đạt được những kết quả sau đây:
1. Đã tìm hiểu chi tiết về các mô hình điều khiển truy cập, đánh giá được điểm mạnh và điểm hạn chế và những ứng dụng cụ thể của từng mô hình, đưa ra ứng dụng của từng mô hình trong thực tiễn.
2. Đã tìm hiểu chuyên sâu về họ các mô hình điều khiển truy cập trên cơ sở vai trò (RBAC), phân tích chi tiết từng mô hình của RBAC và nhấn mạnh vào mô hình nền tảng RBAC0.
3. Đã tìm hiểu bài toán kiểm chứng. Xây dựng mô hình duyệt cây cú pháp trừu tượng (AST), đưa ra thuật toán kiểm chứng hoàn thiện cho các mô hình của
RBAC, đưa ra bài toán nhỏ để kiểm chứng mô hình RBAC0.
4. Hoàn thành việc cài đặt và triển khai bài toán trên Eclipse tích hợp công cụ
CDT. Đã đưa ra kết quả chạy chương trình hoàn toàn khớp với kết quả mong muốn, chương trình chạy ổn định khớp với thuật toán cả về mặt lý thuyết lẫn thực tiễn.
Tuy nhiên do hạn chế về mặt thời gian nghiên cứu, khóa luận khó tránh khỏi những khiếm khuyết kể cả về mặt lý thuyết lẫn việc phân tích và thiết kế công cụ hỗ trợ. Những mặt hạn chế này bao gồm:
1. Mới chỉ tìm hiểu ở mức độ cơ bản bài toán kiểm chứng. Dừng lại ở kiểm chứng mô hình RBAC0 và với mã nguồn C/C++.
2. Vẫn còn “hard-code”, bài toán chưa mở rộng cho nhiều ngôn ngữ và các trường hợp Test chưa nhiều.
3. Giao diện chạy chương trình còn đơn giản, chỉ là console. Chưa tạo giao diện input và output chuyên nghiệp.
Trong tương lai, chúng tôi sẽ tiếp tục mở rộng đề tài này theo hướng nghiên cứu chuyên sâu về thuật toán để kiểm chứng với nhiều ngôn ngữ, mở rộng với nhiều mô hình
RBAC hơn, không chỉ dừng lại ở RBAC0, tránh tối đa việc “hard-code”. Chương trình sẽ có giao diện chuyên nghiệp hơn và các chức năng sẽ thân thiện hơn với người sử dụng để ứng dụng thực tế trong lĩnh vực cụ thể.
Tài liệu tham khảo
[1] David F. Ferraiolo, Dennis M. Gilbert, and Nickilyn Lynch. An examination of federal and commercial access control policy needs. In NIST-NCSC National Computer Security Conference, pages 107{116, Baltimore, MD, September 20-23 1993.
[2] Common Criteria Editorial Board. Common Criteria for Information Technology Security Evaluation, December 1994. Version 0.9, Preliminary Draft.
[3] Imtiaz Mohammed and David M. Dilts. Design for dynamic user-role-based security.
[4] Roshan Thomas and Ravi S. Sandhu. Conceptual foundations for a model of task based authorizations. In IEEE Computer Security Foundations Workshop 7.
[5] Ravi S. Sandhu. Lattice-based access control models. IEEE Computer, 26(11):9{19, November 1993.
[6] Dirk Jonscher. Extending access controls with duties|realized by active mecha-
nisms. In B. Thuraisingham and C.E. Landwehr, editors, Database Security VI: Status and Prospects.
[7] David Ferraiolo and Richard Kuhn. Role-based access controls. In 15th NIST-NCSC National Computer Security Conference.
[8] M.-Y. Hu, S.A. Demurjian, and T.C. Ting. User-role based security in the ADAM object-oriented design and analyses environment. In J. Biskup, M. Morgernstern, and C. Landwehr, editors, Database Security VIII: Status and Prospects. North-Holland, 1995.
[9] Matunda Nyanchama and Sylvia Osborn. Access rights administration in role-based security systems. In J. Biskup, M. Morgernstern, and C. Landwehr, editors, Database Security VIII: Status and Prospects. North-Holland, 1995.
[10] S. H. von Solms and Isak van der Merwe. The management of computer security profiles using a role-oriented approach.
[11] ISO/IEC 10040. Information Technology Open Systems Interconnection { Systems Management Overview.
[12] Ravi S. Sandhu. The typed access matrix model. In Proceedings IEEE Com- puter Society Symposium on Research in Security and Privacy.
[13] Jonathan D. Mo_ett and Morris S. Sloman. Delegation of authority. In I. Krishnan and W. Zimmer, editors, Integrated Network Management II.
[14] Eduardo B. Fernandez, Jie Wu, and Minjie H. Fernandez. User group structures in object-oriented database authorization. In J. Biskup, M. Morgernstern, and C. Landwehr, editors, Database Security VIII: Status and Prospects. North-Holland, 1995.
Phụ lục A1: Cài đặt Công cụ CDT
1. Khởi động Eclipse (GANYMEDE): vào Help chọn Software Updates
Sẽ hiện ra giao diện sau :
Ta chọn Add Site như trên thể hiện sẽ đến giao diện sau:
Nhấn nút này
Chọn Archive… để đến được vị trí của file CDT-mASTer-6.0.0- I200902031437.zip file này có thể download trên mạng theo địa chỉ:
http://download.Eclipse.org/công cụs/CDT/builds/6.0.0/I.I200902031437/index.html
Đến các bước tiếp theo cứ thực hiện như cài đặt một chương trình phần mềm bình thường.
2. Cài đặt MinGW
Chỉ cần download file MinGW-5.1.4.exe và tiến hành cài đặt là được Download ở trang:
http://www.mingw.org/
Giao diện khi cài đặt các bước lần lượt như sau:
Nhấn vào đây
Phụ lục A2: Cấu hình các file để chạy chương trình Test trên C/C++ 1. Thêm vào các thư viện liên quan
Cấu hình trong file MANIFEST.MF
Giao diện tiếp theo khi chọn để cấu hình:
File này
2. Cấu hình lại các Plug-in
Nội dung file plugin.xml phải như sau:
<?xml version="1.0" encoding="UTF-8"?> <?Eclipse version="3.2"?> <plugin> <extension point="org.eclipse.ui.actionSets"> <actionSet
label="VisitorCPPAST"
visible="true"
id="VisitorCPPAST.actionSet">
<menu
label="Sample &Menu"
id="sampleMenu"> <separator name="sampleGroup"> </separator> </menu> <action
label="&Sample Action"
icon="icons/tree.gif"
class="visitorcppAST.actions.GetProject"
công cụtip="Visitor"
menubarPath="sampleMenu/sampleGroup"
công cụbarPath="sampleGroup"
id="visitorcppAST.actions.GetProject">
</action>
</actionSet>
</extension>