Trivial Role-based Authorization-Context State-machines (TRACS)

This project is the first spin-off project of the Security Incident Policy Enforcement System project. In the process of designing a SIPES, the need was recognized for the implementation of an authorization server that provides functionality not provided by any of the current authorization solutions. The introduction of state into the authorization process is crucial for the future integration of automated security incident response with authorization processes as outlined in the SIPES white-paper.

Authorization and incident response

For some time now I've been looking into the subject of combining risk analysis with incident response in order to create a viable and solid framework for (semi) automated incident response handling. The TRACS project aims to create an authorization system that can provide tight integration between the authorization system and a semi automated incident response systems. Such integration is crucial for the implementation of truly reactive risk based security.

So why create yet an other authorization system one might ask? What is wrong with existing authorization systems?

To answer this question we must take take a look state with respect to risk. Authorization systems grant or deny access to users or processes based on static or dynamic rights of these users or processes. We thus can see that these users, with respect to the authorization system can posses a form of state. Dependent on the type of authorization system this state could be modeled as either roles or capabilities. If we now look at authorization from the point of view of risk analysis, than we see that not only the users hold state that is relevant, but so do the resources that access is being granted to, and the software systems that form proxies between the user and the resource. From a risk point of view there exist 3 distinct forms of risk concerned with authorization, and an authorization system that has to be incident response ready will need to be configured taking into account these 3 types of risk, and taking into account the statefulness of users, proxies and resources:

The risk of failure to prevent unauthorized access to a resource.
The risk of failure to give authorized access to a resource.
The risk of authorized access to a compromised resource.

As stated these risks are determined by:

The state of the user or initiator
The state of proxy systems
The state of the resource or target

Role bases authorization systems and Capability systems

Having stated that existing authorizations are not quite suitable for incident response ready authorization, this does not mean that we will have to create an authorization system without the help of some powerful concepts from these existing systems. We will look first at two important but rather distinct ways of looking at authorization, and what useful ideas we might steal from these systems in order to create am incident response ready authorization system.
Role based systems have become common amongst authorization systems, although what exactly is role based seems to be defined rather fuzzy. In its simplest form a role is just a building block for profiles. An intermediate between rights and users. In this simplest form a role has a set of rights, and a user a set of roles. No state involved there, only a more manageable way way to assign rights to users. A second type of role based systems does involve some state. In this type of system a user can assume a role from its profile, only one role at a time. Hybrid forms between these two also exist, and are very powerful way of working with role's. These hybrid forms however fall outside of the requirements for an incident response ready authorization system, and as we aim to create a trivial system, we will look at these hybrid form no further.
The second type of role based system appeared to be very interesting as starting point for incident response capable authorization. We see that there is already a form of state maintained for users, and that this state determines the rights of the user. With incident response however, not only the state of the user, but in many cases also the state of the target and intermediate proxies are equally as important. What we thus need to do is to define a role based system where the use of role's is not restricted to just users, but is available for any of the nodes involved in the authorization process. The system will thus basically become a role based system, only with a more loose definition of role.
Capability based systems are quite a different way of looking at things. Capability systems are an extensive subject, and fully going into them will require to much diversion from the important question of what can we steal from these systems. So with my sincere apologies to the people who have done impressive work on capability systems like eros , I will give a somewhat simplified explanation of the relevant (stealable) parts of capability systems. In a capability based system, if we take the trouble to translate the vocabulary of capability systems to the vocabulary we have thus far been using, for an Initiator to perform an Event on a Target, it is required to have a Capability (a form of a rights ticket) that enables this. So why is this important for incident response purposes? The point is that giving or revoking capabilities itself also are actions governed by capabilities. So giving something like a special capability revocation capabilities to an incident response system, could allow for more extensive incident response procedures to be implemented on (semi) automated basis. Further, capability systems use the concept of everything is a resource, again this is an extremely useful way of working, given the fact that we earlier have discovered that everything has relevant state. It is important to state that in contrast with the initial design, the TRACS system will NOT be a capability system, we choose to primary use the extended role based model, where all rights belong to a type of role, instead of using the ticket like capabilities that belong to the stateful objects directly.
We thus will end up with a role based system that borrows strongly from capability bases concepts, but remains basically still an extended role based system, not a capability system.

what do we steal, what do we add

So lets summarize and translate the concepts we will steal from role and capability systems to use in our TRACS system:

Everything is a (stateful) object (stolen from everything is a resource in capability systems)
The state of a state-machine is the role of the object (stolen from extended role based systems)
Rights are owned by a role, not by an object.
The system can be and will be applied to itself (stolen from capability systems)

So far for stealing, now lets see what we will need to add that we had to come up with ourselves, we will explain these later on:

Stateful objects are represented by templated state-machines.
Rights are fully symmetrical (lefts and rights)
Within a role, rights are owned by a context, not the role itself.
Both stateful objects and events are members of one or more object-groups.
A single right in TRACS is the right to direct (or receive) an event that is member of a specified event-group at a stateful that is member of a specified statefullgroup, and has a context that falls within a specified context range.

Everything is a stateful object

Where in capability systems, everything is an resource, in our context based system everything is a stateful. That is, every external entity (external to the authorization system) is recognized to have state. The authorization system will need to try to keep an up to date representation of this state. The way this can be accomplished is by having the authorization system use an internal state-machine that represents the external stateful object and its apparent state. In stateful role based systems, the only state changes are done by a user taking the initiative to changing its active role. While these types of state changes will also be usable in our authorization system. we have the prime goal of taking into account the needs of incident response. We thus, next to user initiated role change events, will have a state-machine that also changes state based on events generated in the context of (semi automated) incident response.

Events and State-machines

Where in existing role based authorization systems the state that defines the active role can be changed by role change request events, its implementation of changing state on events is not done by representing users as state-machines. While we can borrow many concepts from existing role and capability systems, the generalization of security event driven incident response and user initiated role change events into such a representation is a concept that is truly specific to our needs. As we have stated that everything is a stateful object, not just users, we end up with all stateful objects having a state-machine representation inside the authorization system. Such a state-machine will change state as a result of events being directed at it. These events could in many cases be directed directly at the stateful object, but in other cases, the events are if you will send using a multicast to an object-group. The generalization of stateful objects to state-machines makes for a very powerful and flexible way of defining incident response ready authorization, and risk analysis driven configuration of the authorization system.

Stateful objects are represented by templated state-machines

With powerful and flexible solutions may come the price of extreme efforts in the creation of working configurations. We should thus also concern ourself a bit with different ways of being able to make a large configuration a bit more compact, and able to reuse particular parts of the configuration. Although this more compact configuration will come with its own bit of added complexity, it seems like a reasonable price to pay for the reduction of otherwise extremely extensive configurations. From this point of view we look at state-machine definitions, and see that in many cases objects of a simular type might also have simular state-machine representations. We thus will define state-machine templates, where multiple stateful objects might share the same template, but could for example assign an other distinct role to a particular state.

The state of the state-machine is the role of the object

The most important property of the state-machines is the fact that it will posses a single well defined state at any given point in time. We have seen in role based systems that the rights a particular user had dependent on its active role. The state-machine that is defined for a stateful object will for every state of the state-machine also have a distinct role defined.

Rights are owned by a role and Within a role, rights are owned by a context

Where in existing role based systems, the rights are owned by or determined directly by the role alone, in our TRACS authorization system however, other than in user only role based systems, the context (initiator/proxy/target) is an also relevant. The same object could for example for one operation be a proxy and for an other operation be the target. Its the same object, the same role, but used from within a different context. It is clear to see that the rights a stateful object within a particular role has will depend on such context. We thus will state that every role will have multiple contexts, and rights do not belong at the role level, but are only defined at the particular context for that role. This extra layers however produces one important question we need to tackle: Do we define rights between context and context, between context and role, or between context and stateful? As with templated state-machines, again we choose to ad a little bit complexity in order to keep the extensive configuration a bit more compact. If we were to choose for rights from context to role we would end up with the most compact configuration, there are however also other issues to consider, one of them being that we want our system to be applied to itself. In order to do accomplish this we define that rights go from context to stateful, not from context to context, and in order to compensate for the thus lost more compact configurations, we choose to define these stateful objects in rights by their membership of an object-group.

Rights are fully symmetrical

With rights going from context to stateful objects, we introduce a new problem. Some authorization systems like for example capability systems have rights (capability tickets) that are owned by some form of Initiator, while other authorization systems that are more commonly used have rights (ACL's) that belong to some form of Target. If rights were chosen between entities at the same abstraction level, than the choice for either the Initiator owned or Target owned would give the same range of motion that existing authorization systems of those types give, and with this being sufficient for those solutions, it would surely be sufficient for our trivial incident response ready authorization system. (Please note that trivial refers to the system itself, and the underlying principles, unfortunately not to human process of constructing the configuration for the system, what is meant to be the result of a thorough risk analysis and a deep understanding of the concepts described here). By choosing for rights going from context to stateful object, in order to keep at least the same range of motion, we are thus required to implement both. For many people this is a difficult concept to understand. On the same abstraction level implicit rights and ACL's are in most configurations basically two different views on the same matrix, and many will in their head translate between the two views. In order to understand how TRACS uses these rights in a symmetrical way to compensate for the asymmetrical definition of rights, you will have to let go of thinking of rights and ACLs as such a matrix, and will need to mentally embrace the somewhat strange definition of rights. In order to distinguish between the two types of rights we will define the implicit rights simply as rights and the ACL type of rights as lefts. It is extremely important to understand that for any action or event to take place, it is the pairs of lefts and rights that constitute if the action or event is authorized. Understand this, and you will have understanding of context based authorization as used by the TRACS authorization system.

From Initiator/Proxy/Target to Contexts

Thus far we have identified 3 distinct contexts, but are these truly all relevant contexts? Any operation will always have one initiator, and will always have one target, but the number of proxies might vary, and rights and lefts between different proxies might in many cases be required. We thus identify one initiator, a varying set of proxies and a target, that are chained together in one authorization request for a particular event. In order to arrive at a simple definition for the contexts, we could denote a particular context by a number that identifies its distance from the initiator, or by a number that denotes its distance from the target. We have already seen that we have two types of rights, the rights and the lefts, and we have seen that rights are directed at some type of target (could also be a proxy to the target), while lefts are directed at some type of initiator (could also be a proxy for the initiator). We thus could define two vectors of contexts.

A leftvector where the index denotes the distance left of the target
A rightvector where the index denotes the distance right of the initiator

The role as context-matrix

With a role being the container for all rights/lefts, we could define the role's using the two context vectors, that together form a simple context-matrix. This context-matrix could hold all the rights/lefts for this role, when used within specific operations and within a specific context. If we state that the contexts of the right-vector hold rights, and the contexts of the left vector hold lefts, we end up with a reasonable simple representation of a role's rights and lefts, where the left/right pairs required between stateful objects for an operation are defined using the same indices. This last feature is important mostly for the human mind to design and implement configurations for TRACS.

Applying the system to itself

Next to Stateful objects that represent the external reality, there is a set of object types that all have rights (and lefts) in a different way, that are needed to create a dynamically role and capability based administration of the authorization database itself. Any TRACS-Objects may have 'implicit' contexts depending on its type. All Stateful have at least one context in the left-vector of its implicit context-matrix, while some types might have multiple contexts in their left-vector and even multiple contexts in their right-vector. The types of the objects are the following:

StatefullType: These objects are used for the definition of distinct types of stateful objects, these could be concepts like user, computer,user-process,server-process etc.
StateMachineTemplate: These objects are used to hold XML state-machine templates.
Stateful: These objects are used to represent external stateful objects. (external to the authorization system)
Role: These objects are used for the definition of roles and their (explicit) context matrix.
Event: These objects are used to define any type of event or action that may need authorization.
Object-Group: These objects are used for the definition of groups of objects of any type.

A TRACS Rights and Lefts

A single right/left in TRACS is the right to direct (or receive) an event that is member of a specified object-group (of events) at a stateful that is member of a specified object-group, and has a context that falls within a specified context range. Lefts and rights are owned by an implicit context or explicit (role) context, that itself also has a direction and a distance. Lets show how this works using the I/P/T concepts, showing the capabilities between Initiator Proxy and Target in a single proxy situation as an example. Lets first look at the distances.

The initiator has a distance 0 from the initiator.
The initiator has a distance 2 from the target.
The proxy has a distance 1 from the initiator.
The proxy has a distance 1 from the target.
The target has a distance 2 from the initiator.
The target has a distance 0 from the target.

As shown before, there are 3 rights and 3 lefts required in this setup, lets translate:

The Initiator needs the right to initiate the Event towards the Target.
- The right-vector[0] context of the initiator needs a right with:
  - The event in its event object-group.
  - The target stateful in its object-group.
  - The value 0 within its context-range.
The Initiator needs to have the right to ask the Proxy to forward the Event.
- The right-vector[0] context of the initiator needs a right with:
  - The event in its event object-group.
  - The proxy stateful in its object-group.
  - The value 1 within its context-range.
The Proxy needs the capability to forward the Event towards the Target.
- The right-vector[1] context of the proxy needs a right with:
  - The event in its event object-group.
  - The target stateful in its object-group.
  - The value 0 within its context-range.
The Target needs the left to have the Initiator initiate the Event on it.
- The left-vector[0] context of the target needs a left with:
  - The event in its event object-group.
  - The initiator stateful in its object-group.
  - The value 0 within its context-range.
The Target needs the left to have the Proxy forward the Event to it.
- The left-vector[0] context of the target needs a left with:
  - The event in its event object-group.
  - The proxy stateful in its object-group.
  - The value 1 within its context-range.
The Proxy needs the left to get asked by the Initiator to forward the Event.
- The leftvector[1] context of the proxy needs a left with :
  - The event in its event object-group.
  - The initiator stateful in its object-group.
  - The value 0 within its context-range.

If we view the set of Initiator,Proxy,Proxy,....,Proxy,Target as a vector V of sets of contexts belonging to the current states of the stateful objects and/or TRACS-Objects, than we can model the checking of the full set of capabilities using the following pseudo code:

for i = 0 to ( V->size() - 2 ) do {
  for j = 0 to ( i - 1)  do {
     k=V->size() - j;
     CHECK(  V[i]->Role()->Context(i,RIGHT)  , V[k]); #The right between the Ith and Kth element
     CHECK(  V[k]->Role()->Context(j,LEFT)   , V[i]); #The left  between the Kth and Ith element
  }
}

To give some flexibility, and limit the amount of rights and lefts needed, we state ed before that that a left or right can define a Range of distances. We thus define a left or right to consist of the following fields:

Event-group : The group of events this capability pertains to
Object-Group : The group of objects (stateful objects or objects with an implicit context-matrix) in which the subject must reside.
Distance-Range : The range of distances where the subject may reside.

Target platforms

The TRACS system has a different set of target platforms for different parts of the implementation.
LibTracsCoreThe The TRACSd server library will be implemented with as target primarily the Solaris and Linux platform. *BSD and OS-X may follow, but MS-windows platforms and OS-9 are not planned as target.
TRACSd The TRACS RPC server will be implemented with as target primarily the Solaris and Linux platform using secure sunRPC with kerberos5 authentication. *BSD and OS-X may follow, but MS-windows platforms and OS-9 are not planned as target.
LibTracsProxy: The server side secure sunRPC/kerberos5 based library for TRACS will have Solaris,Linux, windows-2000,*BSD. OS-X as primary platform Windows-XP, AIX, True64 and IRIX may follow. Windows-NT windows-9x and OS-9 are not planned as target.
LibTracsClient:The sunRPC/kerberos5 based library for clients, will be implemented with as target primarily the Solaris and Linux platform. *BSD, OS-X, windows-2000 and windows-XP may follow. Windows-NT windows-9x and OS-9 are not planned as target.
TracsFuse The filesystem wrapper for fuse will provide a TRACS wrapper around excisting filesystems, and tools to administer roles and capabilities, only on the Linux platform, in order to make the filesystem into a capability based filesystem and work as proof of concept for the TRACS model. The first version will be written directly against LibTracsCore, but after TRACSd and LibTracsClient are available will also be ported to LibTracsClient, hopefully with little changes required.

The reasons for this are as follows:

Supporting Windows-NT windows-9x and OS-9 will simply require to much effort for systems that will most likely be phased out anyway. It would be great to support them, but I don't see me having time for the extra effort in design and implementation that I expect this would take. Modern operating systems including win2000 and up use kerberos v5 for authentication, supporting these few legacy system will thus make it impossible to effectively use kerberos v5. That is a price I am not willing to pay for legacy system support.
There is only one TRACSd servers required on a network, so implementing it only form my favorite platform (Solaris) might have been an option.However with a lot of x86 only environments in small and mid sized networks, Linux might be a good second platform to support.
With server (authorization proxy) software running on a wide range of platforms, supporting a wide range of serious server platforms (including windows 2000 and OS-X) is essential, however many of these server platforms (AIX,True64 etc) I don't have access to, so these may have to wait untill friendly users help to verify and/or port to those platforms. Kerberos-5 authenticated sun-RPC seems to be winning ground with NFS-v4 being available on the target platforms, however the availability of of this is not completely sure. If it is later shown that this is a big problem on some platforms, we may need to device additional TRACSd/LibTracsProxy/LibTracsClient implementations that make use of other types of (kerberos v5 authenticated) RPC on these problematic platforms.
As any client that can use kerberos to authenticate the user to the server the use of LibTracsClient is meant mostly in environments where a client wants to make full use of the capability system provided by TRACS. I would like these advanced features to first proof themselves on a limited set of platforms (Solaris+Linux) before porting this library to the other client platforms.

Project Status

This project is currently my personal active part of the SIPES project, I am currently approximately half way down the implementation of the core library and bootstrap XML implementation. I don't have much spare time to allocate to it, but the project currently receives my full spare-time attention. The deadline for incoming comments that could have major architectural impact has ended the 31th of December 2004, I still however am open to suggestions that do not require major design changes. Further I would like to hear from people if the above description is clear and understandable, and if anyone would like to help me to revise this documentation in order to make it more readable or more appealing, or even help me with my typos that would be very welcome. Thanks for any input rmeijer@xs4all.nl.

Time Schedule

The current (April 3th 2005) approximate time-schedule for this project is the following:

31-12-2004 : system specs and basic design done OK
05-01-2005 : API definition (under revission), XML schema (under revission)and database definition done
31-05-2005 : first alpha version of LibTracsCore done.
31-07-2005 : first alpha version of TracsFuse done.
31-10-2005 : first alpha version of LibTracsClient done (with TracsFuse ported to it as proof of concept).
31-12-2005 : first alpha version of LibTracsProxy done.
31-01-2006 : beta version of the TRACS distribution done.
31-07-2006 : production stable.

To check on progress check the CVS repository on the Sourceforge project page
This planning is based on my current limited time resources for this project, and based on me being the only developer on this project. I hope to be able to soon allocate some more time on the project, but at least I know this time schedule