KernelSec: Kernel Authorization Model
to Implement Security Policies

KernelSec

KernelSec is a project which began in 2001, before the events of 9/11 but which certainly intensified after that. Its purpose is to improve the effectiveness of the authorization model and hence the security policies that can be implemented. The authorization model is the mechanism by which the operating system allows/denies operations on the computer system and its information and is also called access control. Our work spans from theory to operating system implementation; security is a complex subject and benefits we believe from a multifaceted approach.

The range of techniques we use are very broad, as we are attempting to build practical systems on a new conceptual basis. I have been working with faculty members Robert Sloan, Lenore Zuck, and V. N. Venkatakrishnan. The security group at UIC includes also Dan J. Bernstein and Prasad Sistla as well as other faculty who have partial interests in security. I'm also the director of the enter for Research and Instruction in Technologies for Electronic Security (RITES) at UIC.

Our goal is to produce an authorization system which is

  • Expressive: can provide the exact desired protections,
  • Robust: allows changes to the protection system in a controlled manner (that is, administrative controls), and
  • Analyzable: decrease the complexity of understanding the provided protections.
Previous systems fail to simultaneously the goals of expressiveness, robustness, and decidability (algorithmically analyzable)-- although there are systems which achieve two out of three of these goals.

The expressiveness of our system includes both Discretionary and Mandatory Access Controls (DACs) and (MACs). We have done fundamental work on the design and decidability of these systems.

We view an authorization system as taking place on multiple levels:

  1. Security Policy: which the organization develops to protect itself against attacks,
  2. Security Properties: the decomposition of the Security Policy into abstract system-wide protections,
  3. Authorization mechanism: the technical means of implementing the security properties.
It is our intention to define Security Properties that are non-technical in the sense that they can be both employed and understood by non-computer scientist. Authorization mechanisms, on the other hand, are more technical and require expert understanding to use effectively. To bridge this gap, we intend to automatically analyze the Authorization Mechanism to derive the Security Properties.

This would enable any organization (even households) to be able to design or select appropriate Security Properties and ensure that they are appropriately implemented. In fact, we view four separate roles here: (1) those who implement the Authorization Mechanism; (2) those who verify the Authorization Mechanism; (3) those who produce Security Policy configurations; and (4) those who verify the Security Properties of the configurations. This would enable even the smallest organizations to select their Security Properties and ensure they were appropriately implemented.

We have been exploring these issues both theoretically and experimentally. The theoretical work uses complexity analysis (e.g. decidability) and algorithm analysis and design. The experimental work has been mostly at the kernel layer but also involves user space issues.

The KernelSec operating system dependent components are being implemented in Linux, and consists of components which run both at the process level and as kernel modules. The components are:

  • Security policy description: enables policies to be specified from which the kernel protection scheme is generated.
  • Base kernel protection model: enables strong authentication and precise control over the sharing of data.
  • Networking protection model: provides support for networking security including encryption, authentication, and authorization of the use of networking.
  • Distributed systems model: provides a certificates-based system of providing inter-administration domain authorization and delegation.

Earlier we had done some work on adding security to omegaRPC, by adding cryptography and public key authentication. This work was done at the process level.