Secure Information Sharing

A midterm report submitted to

Network Information and SpaceSecurityCenter (NISSC)

for Spring 2004 Sponsored Project

C. Edward Chow

Ganesh Godavari

1. Project Goal

The project goal is to design and evaluate various access control mechanism for sharing information between various users. Taking various access control mechanisms into account drives the research.

2. Project Status

One Ph.D. student is currently working on this project. We have set up a simulation test bed for evaluating various access control mechanisms. We have currently analyzed the Role Based access control (RABC). National Institute of Standards and Technology (NIST) has recently ratified RABC draft into a standard. RABC is currently being used in various database management systems like Sybase. Trusted Solaris 8 currently has an implementation of RABC. We plan to deploy the access control mechanism on a Access Control Server. In the current stage, there is only one Access Control server. A web site is setup for the update of the project;

2.1 Test bed Setup

In the test bed, we used a Linux machine to act as a access control server, group key management server, Jabber [] instant messaging server. Two Linux machines are being used to run JabberX [] an instant messaging client.

Fig 1 shows the test bed setup

2.2 Analysis of RBAC

In the core RBAC, a user can be assigned to one or more roles, and a role can be assigned to one or more users. This provides flexibility and finer granularity for assignment of access permissions to roles and users to roles. Objects i.e. files are associated with access permissions.

Figure-2 core RBAC

2.3 RBAC Functions

The role assigned to the user is specified in the subject field of an X509 certificate. The user presents his/her certificate to the Access Control Server before requesting for a file access. Access Control Server checks the users permissions against the permissions needed for access.

The Access Control Server accepts a set of commands from the client:

depositFile(M, AccessPriority)

checkoutFile(O)

Where M implies Mandatory Access

O implies Optional

AccessPriority can be classified, unclassified

Other commands can be added when needed

Figure above shows the organizational setup. How ACS provides access controlis depicted in the scenario below

Client P wants to share a document (docblah.txt) with Client X

  • Client P transfers document using depositFile (Manager, classified)
  • Client p send SSL request to ACS
  • ACS validates client p identifies his role as manager
  • ACS adds a record {Docblah.txt, Manager, classified}

Client Y wants to check out the file using checkoutFile()

  • Client y send SSL request to ACS
  • ACS validates client y, identifies his role as team lead
  • ACS checks against record {Docblah.txt, Manager, classified} and rejects file access

Client X wants to check out the file using checkoutFile()

  • Client X send SSL request to ACS
  • ACS validates client y, identifies his role as Manager
  • ACS checks against record {Docblah.txt, Manager, classified} and permits file access

2.4 Preliminary Analysis

Preliminary Analysis of the RBAC standard for information sharing looks very promising. In most organizations users are assigned to various roles based on his job functions. Conflict of interest among roles can occur but not in our current file access model, modification of permissions is not permitted to a file.

3. References

[1] Role Based Access Control

[2] Information sharing