kernelSec

.:Complexity:.

We used kernelSec at UIC in CS 587, Computer Systems Security in Fall, 2006, thus entering into alpha testing. We plan to have a software release in 2007.

.

• November 2006, Poster and demo at Operating System Design and Implementation in Seattle (Radhakrishnan)
• September 2006, Poster at the Midwest Security Workshop in Urbana-Champlain (Radhakrishnan)
• August 2006 poster as Usenix Security (Radhnakrishnan)

.

• November 2006, at Georgia Institute of Technology, Atlanta (Solworth)
• November 2006, at IEEE TrustCol in Atlanta (Solworth)
• October 2006, at IWSEC in Kyoto (Dranger)
• May 2006, at the Midwest Security Workshop in Chicago (Radhakrishnan)
• April 2006, at IEEE International Workshop on Information Assurance in London (Solworth)
• March 2006, at ACM AsiaCCS in Taiwain (Solworth)

As Ravi Sandhu says, "authorization systems which are too complex will either not be used or will be misused". And without doubt, the complexity of authorization systems increase with increasing protections. Are we faced with the choice of insufficient protections or incorrectly (or unused) protections?

The kernelSec project is predicated on the belief that substantial improvements in the complexity vs. protections curve is possible.

The types of protections are well documented in the literature. They include protections for the orgranization (Mandatory Access Controls) as well as providing flexibility when possible (Discretionary Access Controls). The issue of protections is not what is desirable but rather how it is provided; we call this security architecture.

The sources and measures of complexity are more subtle. They can be viewed by different perspects:

• The system adminsistrators who configure and analyze the authorization system;
• the users, who actions are restricted by the authorization system; and
• the programmers who must write code which operates within the constraints of the system

The system administrators need to control the policy by configuring the authorization system. They must tradeoff the needs of the organization to perform its mission vs. protecting its viability. In addition, they need to make the inevitable changes to the system, and this should be done with incremental effort.

The users should be able to do what they are allowed to do with the maximum amount of flexibility. The authorization system should, when possible, adapt to the needs of the users rather than the users adapting the the needs of the authorization system.

The programs interact with authorization system in two ways: through the operations which are denied and through modifications to the authorization state. Since most operations in an operating system can fail, due to authorization or other reasons, accomodating the first issue has been a long time practice of programmers. The second need, to change the authorization state (eg. an object's label) can be minimized by making most changes occur within the authorization system rather than in the application code.