Exploring Implementations of Access Control in the Emerald Programming Language

(1)

Exploring Implementations of Access Control in the Emerald

Programming Language

Eirik Fjellheim Andersen

Thesis submitted for the degree of

Master in Informatics: Programming and Networks 60 credits

Faculty of mathematics and natural sciences

UNIVERSITY OF OSLO

(2)

(3)

Exploring Implementations of Access Control in the Emerald

Programming Language

(4)

Exploring Implementations of Access Control in the Emerald Programming Language

http://www.duo.uio.no/

Printed: Reprosentralen, University of Oslo

(5)

Exploring Implementations of Access Control in the Emerald Programming Language

Eirik Fjellheim Andersen

(6)

2

(7)

Abstract

Programming languages allow one to express solutions precisely and makes it possible to share or reuse them in various environments.

The purpose of this thesis is to explore the implementation of Access Control solutions in the Emerald programming language and its effective- ness there.

In doing so we present several ways to achieve this for Access Control and how they can be made to fit into Emerald programs using existing language mechanisms.

To evaluate the these solutions for Access Control we test them for completeness and performance and compare them to simpler solutions.

By doing this we can demonstrate the challenges in creating these solutions and Emeralds capability as a general purpose programming language.

(8)

ii

(9)

Acknowledgements

First, I would like to express my sincerest gratitude to my supervisor, Eric Jul, for having patience, humour and knowledge. He has been a great source of inspiration and motivation.

Thanks to my bicycle for the times when I would be able take a ride to clear my brain after getting stuck.

Finally, I would like to thank my family for their support, for motivating me through challenging times and for many good dinners.

(10)

iv

(11)

Introduction

(16)

(17)

Chapter 1

Introduction

1.1 General

Programming languages can in many ways be compared to natural languages. They are used to express a meaning in a concise and unambiguous way, both for computers to correctly interpret the meaning of the code, to create the correct instructions and for the programmer to not have to micromanage programs. These programming languages allow us to move onto higher level management in designing solutions that are generic and not just implementing them on a case by case basis for each architecture and operating system.

Languages designed for one purpose are called domain specific languages, which relates to their primary focus of addressing a specific need.

In most cases these languages are more limited than general purpose programming languages, allowing them to excel at solving a specific set of challenges. Some domain specific languages are also capable of being used as general purpose programming languages, and since the Emerald programming language has this capability we will use these functions in our work.

In this thesis we will explore various methods and solutions for implementing ways of controlling access to Resources in the Emerald programming language, which can be defined as a domain specific language. In designing and implementing these solutions for Emerald we can explore their usefulness.

1.2 Motivation

Most programs use or alter Resources while they operate. This works in an ideal environment, but unconstrained access to all available Resources are not without side effects. This unconstrained access is unwanted for most programs that shares Resources and aim to be stable, robust and easy to extend.

Without a way to control the access, we can end up with programs that behave unpredictably and chaotically, which is why many programs, operating systems and programming languages are developed with ways

(18)

to manage access and keep its Resources and structures in a logical and working order.

Access Control includes a large amount of challenges arising from programs and Users, which can get into conflict with each other. From those challenges several ways of mitigating this were identified; from solutions embedded in hardware all the way to pure software solutions. As these solutions have developed over time we can observe which designs that have survive and which died out. Based on these solutions we will select what best suit our needs for implementation into the Emerald programming language.

Specifically, we wish to implement some of these existing methods for Access Control into the Emerald programming language, so we can reap the benefits of the established solutions.

We also want to create ways to use Locks, Access Control and Authen- tication in Emerald, which will help programs that need concurrency control and the ability to restrict access to Resources to avoid misuse of Re- sources in the long term.

1.3 Problem Statement

We will implement Locks, Access Control and Authentication by using the Emerald programming language, such that they can be useful for future Emerald programs. Further, we will provide guidance on how to create these solutions for the Emerald programming language in general.

1.4 Goal

The goal is to explore, develop and test implementations of Access Control solutions in the Emerald programming language. We will evaluate the feasibility of these solutions and test the performance in a distributed Emerald environment.

1.5 Approach

We have studied existing solutions and explored papers about Access Control solutions, which let us experience how well they apply to programs made in Emerald, and how they could be implemented. We developed a number of examples of running code to display various solutions and different implementations of the same solution. These were made purely using the existing facilities in Emerald and will not depend upon external libraries. Development and testing was performed mostly in environments that support a plain-text editor and the Emerald compiler i.e. in Windows and Linux based environments.

4

(19)

1.6 Work done

The work includes implementations for programs in the Emerald programming language with variations of Access Control. Below is a list of implementations and programs:

• Basic lockable ResourceObject

• Granular lockable ResourceObject

• List-Based Access control

• Capability-Based Access Control

• Unit and Integration Tests for these programs

• Performance tests for these programs

1.7 Evaluation

Evaluation is divided in two main parts, the Testing which serves to test that the implementations function correctly and the Evaluation which takes an objective and subjective look at the results of the work done.

The testing of the implementations demonstrate that the Access Control solutions works through unit and integration testing. These tests cover the usage (operation) of these implementations ensuring they work as expected.

The objective evaluation is done by performance testing where each implementation is compared against a basic implementation without Access Control functions. The difference is then measured and noted.

The subjective evaluation discusses additional aspects of the implementations we have explored such as how comprehensive the solution is and how maintainable it should be based on its complexity. We also considered possible future work for the solutions and how feasible that would be.

1.8 Results

The solutions developed were tested to provide proof of concept programs that point to methods of incorporating them in future Emerald programs without issues.

1.9 Contributions

The contributions to the Emerald programming language are the development of running solutions for Access Control as proof of concept that these solutions can be implemented in Emerald. These solutions implemented in Emerald has been compared and tested to control implementations without these capabilities.

(20)

1.10 Conclusion

The conclusion from the implementation of the different variants of Access Control is that these solutions work and are suitable for implementation in Emerald programs.

Access Control can be achieved by the following methods:

• An implementation of Locks via a small alteration of operation parameters for a Resource and an additional Lock helper Object to perform the locking logic.

• A further developed method to keep track of access based on key holders or alternatively a method which performs Access Control via Emeralds native restrict to mechanism.

The tests List-Based Access Control revealed that it was on average slower than without this feature. However, tests for Capability-Based Access Control revealed that there was no significant difference than without this feature both for the single node and the cross node tests.

Authorization was planned to accompany the rest of these solutions, but the challenges in implementing it in a distributed system proved challenging and it was decided to take it out of the scope of this thesis.

1.11 Outline

The thesis is divided into four main parts following this Introduction, each comprehensively covering the share of the work as described below. The different parts of the thesis build upon each other so it is recommended to read from beginning to end in chronological order.

1.11.1 Earlier work and background

In this part we describe Locks and Access Control in a historical perspective and discusses different functions of basic and advanced Access control. We also explore existing solutions relating to the problems we are aiming to solve and elaborate on their usefulness in fulfilling the goal.

We give a short introduction to the design and reasons behind the creation of the programming language Emerald and describe functions of interest that can be used for Access Control solutions. Examples of Emerald code snippets are included to illustrate some of these function’s purpose.

1.11.2 Building Solutions

This part is divided into Exploration and Implementation. In the Exploration chapter we investigate the solutions for Access control that is most suited to use in the Implementation. It also contains a description of key points we will consider for the Implementation in the Emerald environment.

6

(21)

The Implementation chapter contains the solutions for the different type of Locks and Access Control in the Emerald environment. Examples of code for the different solutions are included and can be found in the Addendum.

1.11.3 Testing and Evaluation

This part is divided into Testing and Evaluation. In the Testing chapter we describe the testing of the solutions from the Implementation chapter for Locks and Access Control. The testing includes unit and integration testing where we ascertain the completeness of the implementations.

The Evaluation chapter is divided in an objective and a subjective part.

Objective Evaluation includes the results from the performance testing where we compare the implementations against a basic solution with both single node and cross node tests. We also address the maintainability and extendability of the Access Control solutions in the subjective evaluation.

1.11.4 Summary, Discussion and Conclusion

This part gives a short and concise round up of what we have experienced through the work and the results from the implementation and testing.

It also includes discussions on the preferred solutions and limitations in Emerald with some thoughts as to how the results may be used or further developed in the future.

(22)

8

(23)

Chapter 2

Definitions

2.1 General Definitions

Lock

A mechanism to gain exclusive access to a Resource.

Access Control List

A system to manage the access rights of multiple Users centrally.

Capability

A system to give Resource access to Users and have the Users manage it.

Authentication

Verification in computer systems commonly used to check the identity of a User.

Authority

A person or system with the trust or power needed to govern others.

Authorization

The permission assigned by an Authority to perform a task such as access or use of a Resource.

Proxy

An intermediate data system or program between a User and Resource.

Concurrency

The event of multiple tasks being done simultaneously in a system.

2.2 Programming Definitions

User

A person or a program capable of interacting with a Resource.

(24)

Resource

A collection of data or physical objects, which can be used to perform an action e.g. a key to open a door or give access to a data system.

Alice and Bob

These are generic names for User Objects to aid in explanations where many Users interact with a Resource Object.

Object

Data structure in programming languages capable of containing data and executable code.

Emerald Object

Emeralds implementation of an Object, referred to in this document as an Object for short.

Type

Data structure in programs made for specific types of data, which will only accept and store that type of data.

Emerald Typeobject

Emerald specific implementation of types which is a collection of operation signatures where each operation signature includes the operation name, and the names and types of its arguments and results.

Emerald Operation

Emerald programs communicate through procedures called Operations.

Emerald Function

Emeralds second type of procedure, a Function, is a functional operation that guarantees no side effects outside its parameters when used.

10

(25)

Part II

Earlier Work and Background

(26)

(27)

Chapter 3

Background

3.1 Introduction

This chapter contains a description of Locks in a historical perspective and takes a look at known solutions for Access Control in data systems, existing solutions of these in service and an evaluation on incorporation of these into Emerald programs by various methods.

Access Control is a general term to describe the way various systems, such as computers or organizations, control and restrict access to Resources and and can be implemented by use of many different methods. The term Access Control does not describe any specific way to restrict access, but rather the systems that do so.

Locks, whether physical or digital, is a simple example of Access Control where the one holding the key has control of the resource (or physical place). In computer systems it is often used to prevent Users from being able to read or change a Resource.

The terms User and Resource are used to describe the parties that interact in future examples of Access Control systems, a User are those that interact with and can use a Resource.

In computer environments there are a few commonly used implementations for Access Control that I have experienced which I’ll detail below.

3.2 Historic perspective

3.2.1 Locks

Locks have been used to control access to places or resources for thousands of years, there is evidence of primitive locks at least as far back as ancient Assyria and Egypt. These locks were a precursor of our modern day pin lock used to secure doors. Over time these locks were miniaturized and developed into metal locks, which were used to secure lock-boxes and valuables.

With the industrial revolution in the 18th century and beyond more sophisticated manufacturing equipment were made such as metal lathes and tools that ushered in a massive improvement in lock manufacturing

(28)

and security. In this period many variants of pin and tumbler locks were invented and improved upon.

Even with some further improvement in the modern day we still use the basic principles of these locks today for our physical locks, however, with the computer industry and the invention of digital security many locks that were previously purely analogue have now been supplemented with digital versions.

An example of a digital lock is a conventional door lock driven by an electric actuator with remote control from a home automation system.

These systems can have different levels of built-in security and protocols such as Z-wave is open and can be programmed by experienced users.

The society today has an increased focus on security and this drives the innovation for more convenient systems such as biometric security as a replacement for physical keys, pin codes and passwords.

Digital surveillance with cameras has developed from manual surveillance to automated surveillance with face recognition for identification in certain industries and public environments.

This digital development are replacing physical guards and surveyors and will have a large impact on the access control systems in the future.

3.2.2 Access Control

Access Control is a broad umbrella term for all the methods and mechanisms that work together to accomplish the goal of keeping valuables and confidential information secure, and more important, allowing access to the intended people.

As described earlier, Locks are a simple way to control access and may form part of the access control system. As basic locks have existed for a long time, they are very much associated with keeping assets secure and the fulfils the purpose of securing people’s and businesses’ valuables from others in the community.

Access Control has developed from simple Locks to include identification of personnel, surveillance, differentiated access control to areas with different security levels, use of passwords and pin codes, multiple steps of identification to the modern biometric identification of today. There is also a desire to monitor the access to facilities and data systems.

In contemporary society, the focus on information security aligns with the fact that Access Control may be applied to more abstract purposes other than strictly physical measures. An important factor in the modern Access Control system is sharing of information to only the persons that require this information to limit the risk of unintended access.

A simple example of information control is early encryption schemes that simply shuffle letters around and achieve a measure of secrecy by those not privy to the key or the flaws of such a simple scheme.

All these methods have slowly developed over time, eventually diverging into entirely distinct branches of knowledge.

14

(29)

3.3 Basic Access Control

Locks are a simple technique used to control access to or use of a Resource in a computer system. It is often used to exclusively reserve the use of a Resource to a specific User, such that attempts to access or alter this Resource by a different User will result in failure in the form of an error message or even a crash.

It can be noted that there are solutions that are made just to coordinate Users and which does not trigger a failure or error if misused. These locks are known as Advisory Locks and act as guidance for programs to avoid deadlocks.

There are also different ways that Locks can allow access to a Resource depending upon the type of usage it is meant for. For some implementations the Resource can be shared by multiple Users as long as the access is read-only, however, if the Resource needs to be altered then a chance of conflict occurs if multiple Users attempt to alter the same resource simultaneously in incompatible ways.

This also applies if a Resource is removed by a User while it is still in use by other Users.

Locks are also a very common concurrency control mechanism to make sure no unexpected behaviours are created when Resources are accessed and used simultaneously by multiple Users.

A way to achieve this would be Two-Phase locking, which is a very common method to guarantee that the end state of a series of actions is defined and is used in both databases and distributed computer systems.Two-Phase locking happens in two phases in which, first the locks are obtained and secondly they are released.

Locks allows us to make sure that Resources are not modified by other Users while in use and locked, which maintains the integrity of a Resource. Further, we can use Locks for concurrency control and avoid Users simultaneously enacting changes upon the Resource in question.

There are some disadvantages one should be aware of when implementing and using Locks such as the extra processing added for each access to the Resource to check permissions, however the advantages can overrule the disadvantages depending on the application.

We may also experience the appearance of a permanent lock state called a deadlock. This may happen when two Users are waiting on each other indefinitely or the User (program) holding the lock fails unexpectedly before releasing its access rights. This can be solved by releasing any locks automatically under predefined conditions or even removal of the deadlocked Users.

Additionally, important processes may not be able to complete their tasks until a less important process is finished since Locks do not often have any priority or importance between the Users.

(30)

3.4 Advanced Access Control

More developed Access Control methods are able to serve multiple Users at any time and have features meant specifically for the situations that can arise when multiple Users are meant to cooperate. I have observed two main ways of processing the access rights for multiple Users. These techniques are called as Capability-based and List-based Access Control where the distinguishing feature is where and how they store rights to access a Resource.

In the first, Capability based, the access rights are located with User itself which lets it access specific Resources.

For List-based access, the access rights are stored in the Resource itself as a list of Users with access attributes, which specifies the Users that are allowed access it and what they are allowed to do.

3.4.1 Capability-based Access Control

For Capability based access, the access rights are located with the User using tokens calledCapabilities, which contain the access rights of the User.

These Capabilities allow a User to use and access a Resource only to the extent the Capability allows. The Resource does not know who possess these tokens or the types of tokens which exist, only that any User accessing it with a token are allowed to use it within theCapabilitiesof that token.

Using Capabilities a User knows what it has the access rights to do, since all permissions are located within the Capability that the User holds.

Any User is also able to share its access rights to other Users.

Capabilities are also inherently distributed which may be useful in our case for implementation in the Emerald programming language.

Since the Capabilities are stored with the User itself and can be shared with other Users uncontrolled, it makes it difficult or impossible to control the Capabilities of a Resource. This can become a problem with excessive sharing, and revocation may prove impossible without collateral damage to other Users access rights.

3.4.2 List-based Access Control

List based Access Control mirrors Capabilities by storing all access rights in a list within the Resource instead of with the User. The Resource then controls any access by performing a lookup (checking the Users key) to see if the User requesting access has the rights required and authenticates requests deemed valid.

Since all access rights are centralized the Access Control of a Resource is more easily managed.

List based Access Control can more easily be checked to determine which Users that can access the Resource and revoke them if needed. In a situation where trusted Users may become untrusted, a list based approach may be best since it enables any program or system administrator to revoke access for untrusted or obsolete Users.

16

(31)

It may prove difficult to find what a Subject has access to and revoking that Users access across several Resources they are not necessarily organized in relation to the Users or in contact with each other.

For cases where a User should be universally allowed or disallowed a shared authority would be needed.

3.5 Authentication

The core of authentication revolves around confirming the authenticity of information whether that is an identity or message, often involving an entity supplying the information that must be verified.

Among other things authentication is also used to ensure that the parties in a communication can be identified and that their messages are genuine.

The basis for authentication is often built using different forms of cryptography to form protocols that ensure the integrity of identities and messages in communication.

There are many approaches to solving authentication issues, some of the more common solutions are based on public and private keys, cryptographic challenges, digital signatures and certificates.

Cryptography’s main use area is to keep secrets and integrity of a system and is therefore well suited to this kind of use.

The authentication philosophy is strongly linked to the issue of trust.

There will be a different degree of trust to the Users depending of the number of Users and if it is a public or exclusive system. The authentication system should be purpose built to the application and consider the consequence of misuse. Issues to consider is if the trust shall be based on singular authority or if a distributed approach can be used. The latter may give a more flexible system.

An important use case for authentication lies in the verification of identities by using different factors, these are often broken down into three distinct groups.

• A parameter that is known, such as passwords and/or identification name/number

• A parameter the User possesses, often a physical token of some kind.

It can also exist purely in software, albeit with some additional risks

• A parameter the User is linked to or can do that can uniquely identify them with sufficient granularity

Building on these parameters, we can then construct a system using any combination of these factors to improve security and make the system more reliable. Depending on how strong the security needs are, it may suffice to use only one or two of the factors for such applications as public forums and web accounts and several factors for applications such as banking and other financially significant entities.

(32)

3.6 Summary

Access Control and the corresponding authentication can be built on different available techniques depending on the application. In this chapter we have discussed methods for simple and Two-Phase locking, more advanced access control by means of Capability-based and List-based Access Control, and different ways of Authentication.

All of these different techniques contribute to building solutions where one can easily and properly restrict Resources depending on usage and the User. Whether that restriction needs to allow for single or multi user situations, or allow for sharing of privileges or not, will depend on the application and the required Access Control.

18

(33)

Chapter 4

The Emerald Programming Language

4.1 Introduction to Emerald

Emerald is a general programming language [25] made primarily for distributed systems and has implemented native methods to make creation, distribution and management of Objects over several nodes easy. These nodes may be geographically separated and handling these situations on a language level allows a more elegant control of distributed situations than many other languages which instead implements similar functionality as libraries, modules or add-ons on top of the language.

It started as a research language to prove the feasibility of efficient Object based style of programming in a distributed system. [3]

Such a system may be unreliable, which makes the management of it challenging when you want your programs to be able to continue even if some of the machines it is hosted on is temporarily or permanently severed from the rest of the network or a node crashes unexpectedly.

Emerald provides functionality to mitigate this so that these cases can be handled in a clear way.

Emerald is strongly typed and has an interesting object model where everything revolves around the Object which is used for data, types and more.

In particular the way the Type system works makes Objects quite flexible thanks to conformity which will be elaborated on later. For example; Typeobjects allows a program to refer to Objects that was not there at compile time. A program can use this to access some Objects it would otherwise not be able to without recompiling it.

4.2 Conformity of types

Of particular interest is the way that objects in Emerald’s model relate to each other. The way types (and objects) relate to each other is expressed through Conformity which is one of the core concepts of the language itself.

(34)

Conformity is the basic relationship between types and allow Objects to conform to other objects in a way that can be used to substitute one object for another, allowing for enhancement by adding additional operations or improve the internal workings of an object without touching the names or arguments of the operations changed.

To utilize this property the objects need to relate to each other in a way that fulfills the basic rules of conformity. As long as the objects have these properties they can be said to conform in one direction or both depending on the objects themselves and we can use this to substitute one with the other.

For an object to conform with another object certain requirements have to be met. In a case where object S conforms to T the following is noted:

• S provides at least the operations of T.

• For each operation in T, the corresponding operation in S has the same number of arguments and results.

• The types of the results of S’s operations conform to the types of the results of T’s operations.

• The types of the arguments of T’s operations conform to the types of the arguments of S’s operations.

In its simplest form: a type S conforms to a type T if an object of S can substitute for a type T object. That means we can use S instead of T or replace T.

Take the following code snippets[25]:

1 type J u n k D e l i v e r e r

2 o p e r a t i o n D e l i v e r −> [Any]

3 end J u n k D e l i v e r e r

4

5 type P i z z a D e l i v e r e r

6 o p e r a t i o n D e l i v e r −> [ P i z z a ]

7 end P i z z a D e l i v e r e r

Listing 4.1: Junk and Pizza deliverer

These types conform to each other in one direction, PizzaDeliverer conforms to JunkDeliverer. The reasoning being that the Any type of JunkDeliverer can be substituted with Pizza, so PizzaDeliverer can be used instead of JunkDeliverer. The types do not conform in the other direction, meaning that PizzaDeliverer cannot be replaced with a JunkDeliverer.

An additional example from [25]:

1 type JunkHeap

2 o p e r a t i o n Deposit [Any]

3 end JunkHeap

4

5 type Bank

20

(35)

Figure 4.1: Lattice of types in emerald.

6 o p e r a t i o n D e l i v e r [ Money ]

7 end Bank

Listing 4.2: JunkHeap and Bank

In this case JunkHeap conforms to Bank and can be used instead, the reason for this reversal when using arguments instead of results is listed in the 3rd and 4th rule of the conformity requirements, it’s important enough to make a note of this difference in this example.

4.2.1 Lattice of types

The relations between types in Emerald can be envisioned as a lattice with the type ANY on top and NOONE on the bottom. This is illustrated in figure 4.1 which shows Emeralds type lattice in a simple way. Additionally we have colored the objects that are Emerald native, the objects which are substituting for a programs own objects and an example of a restricted object which will be covered further down.

ANY as a type has no operations and we can therefore assign any object to it since they will always be able to conform to the ANY type.

NOONE as the type of Nil essentially contains all possible operations which means Nil can conform to any other object and be assigned to any variable.

To summarize, an object S conforming to T which can be written as;

S *> T (S conforms to T)

(36)

would mean that the object S can substitute the object T in any operation that normally requires an object of type T.

As an example, if the previous JunkDeliverer and PizzaDeliverer types were implemented alongside an object for pizza this would allow us to substitute JunkDeliverer for a PizzaDeliverer and deliver pizza into the JunkDeliverer:

1 c o n s t Conformity <− o b j e c t Conformity

2 var JunkWorker : J u n k D e l i v e r e r <− J u n k D e l i v e r e r . c r e a t e

3 var PizzaWorker : P i z z a D e l i v e r e r

4

5 PizzaWorker <− view J u n k D e l i v e r e r as P i z z a d e l i v e r e r

6

7 o p e r a t i o n u s e D e l i v e r e r

8 %D e l i v e r p i z z a through P i z z a d e l i v e r e r i n t o J u n k D e l i v e r e r

9 var M o z a r e l l a P i z z a : P i z z a <− P i z z a . c r e a t e [ ‘ ‘ Cheese’ ’]

10 PizzaWorker . D e l i v e r [ Mozarella ]

11 end u s e D e l i v e r e r

12 end Conformity

Listing 4.3: Conformity

The view-as statement can also allow type widening and type narrowing, which means that a type can be presented to look like another with more or less operations as long as they conform to each other. In a way one can "translate" an object into another within within the limitations described above.

1 view S as T

Listing 4.4: Viewing an object as another

In this case we show how the object of type S is made to look as if it was an object of type T for use as a substitute or upgrade to the previous version on the fly.

A previously narrowed object can be widened again to regain the operations that was hidden in the process later on.

If this is not desirable a permanent widening or narrowing of a type is also possible with another statement called restrict-to, which is more restrictive regarding type widening and narrowing.

4.3 Emeralds Restrict-To mechanism

When we narrow or widen a type, the result is essentially an object with fewer or more functions than the previous? object being used. This can be used for sharing objects that have previously been restricted to avoid use

22

(37)

of incompatible objects or misuse of functionality to, essencially becoming a type of Access Control capability.

There are however a large drawback to this, namely that you can simply re-widen the object again after receiving it. This is where the restrict-to statement is used:

1 r e s t r i c t S t o T

Listing 4.5: Restricting an object

This statement prevents any future type widening of the S object and any attempt to do so will result in failure. This is particularly suited to use cases where sharing an unrestricted object may result in unacceptable consequences and is suitable for being used as a component of an access control mechanism.

As an example of the use of such functionality, we can create an object that can be restricted from a read-write functionality state to a write-only state:

1 c o n s t u n r e s t r i c t e d <− t y p e o b j e c t u n r e s t r i c t e d

2 o p e r a t i o n p r i n t

3 o p e r a t i o n i n c r e a s e [I n t e g e r]

4 end u n r e s t r i c t e d

5

6 c o n s t r e s t r i c t e d <− t y p e o b j e c t r e s t r i c t e d

7 o p e r a t i o n p r i n t

8 end r e s t r i c t e d

Listing 4.6: Types to be restricted

The above types will be our basis for restricting an object that conforms to the below types.

1 c o n s t T e s t <− c l a s s T e s t

2 var value : I n t e g e r <− 0

3

4 e x p o r t o p e r a t i o n i n c r e a s e [ i np ut : I n t e g e r]

5 value <− value + in pu t

6 end i n c r e a s e

7

8 e x p o r t o p e r a t i o n p r i n t

9 (l o c a t e s e l f ) $ s t d o u t . p u t s t r i n g [" Value : " ||

value . a s S t r i n g ||" \n "]

10 end p r i n t

11 end T e s t

Listing 4.7: Object implementing the unrestricted Type

This will be our test object, which we will create copies of to restrict as needed.

1 var U n r e s t r i c t e d O b j e c t : u n r e s t r i c t e d <− T e s t . c r e a t e

2 var R e s t r i c t e d O b j e c t : r e s t r i c t e d

(38)

3

4 R e s t r i c t e d O b j e c t <− r e s t r i c t U n r e s t r i c t e d O b j e c t t o r e s t r i c t e d

Listing 4.8: Restricting the Object

Using this code will create an unrestricted object and then a copy of that object restricted to only reading from the unrestricted object.

Any use of the following code to attempt to unrestrict a previously restricted object or a theoretically conforming object in the attempt to widen it, would be met with a failure message.

1 view R e s t r i c t e d O b j e c t as u n r e s t r i c t e d

2 view R e s t r i c t e d O b j e c t as o t h e r L a r g e r O b j e c t Listing 4.9: Behavior not allowed after restriction

4.4 Emerald Classes

Emerald does not have a class type, classes are made through a syntactic construct that provides the necessary functionality of a class. These objects are not distinguishable from standard objects and any class functionality is build on top of Emeralds existing object functionality.

Emerald also supports single inheritance where the sub-class inherits among other things the operations and variables of the super-class, we will be using this to make implementation of the solutions easier to work with.

4.5 Nodes

Emerald was designed to help with programs that span multiple computers connected by a network, for that purpose it has the concept of Nodes that represent the points in the network running Emerald processes. Any Emerald program on these nodes are able to communicate, and regardless of actual location call upon any other program in the same network.

Emerald programs may also move objects across the network to any node, this is useful to address the performance and availability of objects in the network. An Emerald Object may move another object close to itself for faster access, this also guarantees the objects availability for the time it stays at that Node.

Emerald objects may also be fixed at a particular node, in these cases they become unmovable so unless a copy can be used locally performance is likely to be less than a local object.

Emerald also provides built-in support to move objects across this network of nodes, this takes the form of Emerald specific syntax that programs can use to move Objects, including themselves, across these nodes as needed.

Below is an example of moving an Emerald Object between nodes:

24

(39)

1 var nodes : NodeList <− (l o c a t e s e l f ) . g e t a c t i v e n o d e s

2

3 i f nodes . upperbound − nodes . lowerbound + 1 < 2 then

4 s e l f . p r i n t [" Need a t l e a s t 2 nodes\n "]

5 r e t u r n

6 end i f

7

8 move R e s o u r c e O b j e c t t o (l o c a t e nodes [ 0 ] $thenode ) Listing 4.10: Moving an Object to another node

4.6 Additional reading

Emerald is described in the following papers and reports: [4, 10–20, 26, 27, 29].

4.7 Summary

Emerald has an interesting and flexible version of Types and Objects with functionality that lets Objects substitute and replace each other in a structured way even when programs are running. Objects may also viewed and used as if they are an Object of a different Type as long as their Types conform to each other. The Restrict-To mechanism can restrict Objects from being able to add more operations than currently exists at the moment they are restricted.

Emerald is also built with distributed programming in mind and has design considerations and mechanisms that makes it possible for programs to communicate and move seamlessly across a network of nodes.

(40)

26

(41)

Part III

Building Solutions

(42)

(43)

Chapter 5

Exploration

5.1 Introduction

In this chapter we will explore the solutions we intend to implement into the Emerald language.

We will go through each solution in the order they were introduced earlier; Locks, Access Control and then Authentication. Each solution will be looked at through two perspectives; one general and one Emerald specific.

At the end we will explore how the solutions relate to each other and synergies between them.

5.2 Locks

5.2.1 Introduction

Locks are simplest of all the methods we will be covering and a good starting point to explore basic Access Control.

Locks are a well known and utilized solution for cases where one wishes to restrict access based on a number of simple criteria. Locks in software also matches well with the common society as it is also a household object that most people have experience with. The purpose of locks is to deny access to a place or object such as a house or a car.

In software we can extend this to more abstract purposes, like access to information in a database or the right to run a program.

5.2.2 Motivation

The objective is to explore the different methods used for Locks as a preface for the solutions we will develop as described in chapter 6. As Emerald is a programming language, it does not deal with physical items but rather the objects and data structures in a computer system. Some of these objects can be compared with valuables, and it would be prudent to secure these.

We wish to gain the ability to regulate access to Resources in Emerald.

(44)

With the implementation of Locks in Emerald, we want to be able to control access to Resources. This will give more options to keep coherency when needed, as Emerald has native functionality for running multiple objects in a distributed network.

It will also be possible to use this implementation for security, which we will take advantage of and use as a springboard to build better and more sophisticated Access Control solutions. This is also covered in chapter 6.

5.2.3 Challenges and limitations General

When trying to restrict access to a facility or data system, there are a number of challenges to consider:

• The properties of the object you want to secure

• The number of access points

• The different categories of personnel that need access

• If the data system requires remote access or not

• If it is a distributed or central data system

• Different levels of access

Depending on the scope and criteria, the solutions may require excessive investments or run into technical challenges that goes beyond the budget available or a realistic technical implementation. The reliability must also be considered. A non-critical solution may have less reliability than a critical solution depending on the consequence of failure and if there exist mitigations in place for such events.

The main consideration in designing a Lock is to perform its basic function within the scope of the task assigned, meaning if you Lock a door it should not open for anyone but the key-holder and it mustnotto be easy to bypass it.

Having several steps to go through to properly secure a facility or data system, can be a burden in many cases. There are also issues where keys are lost or forgotten, which also leads to security problems, delays and extra work. Some of these issues may require extensive correction. The problem of losing access to an object you should rightfully be able to access, is a driving force for making security more independent of key cards and passwords.

Issues such as forgetting passwords, are common and there are many redundant systems to mitigate these problems, such as recovery email addresses and customer service to regain access in cases where a user has been locked out. It is not uncommon to lock oneself out of their own car or house. Since most of these issues are related to common faults, the systems have implemented services to regain access, at a certain cost.

30

(45)

Depending on the needs, the solution can either be an analogue or a digital system. Analogue systems depends on physical keys, locks and sometimes people that guard or survey. If you want to secure a place you want a door or gate with a lock, and if the place is important enough then guards or surveillance systems would be needed too.

In an Emerald environment

For Emerald we have to implement a solution that allows reserving the use of a Resource by a User in a way that cannot be bypassed.

Getting the balance right between functionality and performance will also be challenging depending on what solutions that are available, so we will explore that in the next chapter chapter 6. In a programming environment, we can be considerably less forgiving of mistakes as long as we have ways to correct them. Our solution will, however, encounter other drawbacks that are unique to a computer environment. As an example any possibility has to be accounted for in advance, and malfunctions such as deadlocks will have to be avoided or worked around.

5.2.4 Proposed solutions

In the Emerald environment, I will implement a solution to allow an Emerald Object to be restricted to allow for exclusive access to this Object as a Resource. This will be done by emulating a Key and Lock structure by creating a Key that allows for access to the restricted Resource.

To implement this Key we will likely have to alter the Emerald Object that will support locking to receive it. A basic lock would then use that Key to check if the Resource is locked and grant or deny access as needed.

The Lock solution could also possibly support more granular control over the operations that are locked. Alternatively, it might be possible to use an object as a proxy to route communication through and instead do the locking logic there.

We can summarize that we have two main paths forward and a variant for the proposed solutions;

• A basic Lock

• A Granular Lock variation

• A Proxy-Based Lock

Preferably we will also enable some resilience to deadlocks through a mechanism or timer that automatically releases the lock based on a defined criterion.

5.2.5 Criteria For Evaluation

For Locks in Emerald we want to have a solution capable of locking and unlocking an Object making exclusive access possible for use in security conscious and concurrency sensitive applications. This is regarded as the

(46)

basic set of functionality needed to meaningfully test the solution. We also desire to be able to run the solution in a distributed program.

A higher level of control over which parts of a Resource Object that gets reserved is also desirable, but not necessary for a simple implementation.

5.3 Access Control Methods

Access Control builds on many of the principles of both basic and more advanced Locks and extends this to be capable of handling more Users simultaneously and additional control functions. Access Control is a common solution to secure buildings and services alike, most contemporary Access Control solutions rely on dedicated electronic systems to facilitate it. It’s usage lies mainly in restricting, granting and sharing access through defined protocols.

For our solution, Capability-Based Access Control is uniquely suited for implementation in Emerald by its native functionality.

The objective is to explore the different methods used for Access Control as a preface for the solutions we will develop as described in chapter 6.

Locks are suitable as a simple method of avoiding conflicts between Users, but there are cases where a more granular method is preferred to avoid limiting the access of a Resource to one User at a time. This is simple and quite effective, but suboptimal since the Resource has the capability to do multiple tasks.

In Emerald we can build upon the implementation of Locks and extend it to work as an Access Control solution capable of serving multiple Users.

Access Control is more difficult to implement compared to a simple Lock, due to the expanded amount of requirements. A Lock can be regarded as a part of an Access Control system. An Access Control system is more complex, has more functionality with stricter requirements to avoid errors.

In an Access Control system comprising of several parts, the security of the system is only as good as the weakest link. All of these systems also interact with people in some fashion, so the system must also be tailored towards the need of its Users.

The requirements for an Access Control system depends on its purpose and design. In our case, we will allow for a Resource to be shared more

32

(47)

effectively with some granularity in mind for how these permissions are granted. As for the Locks, there will be a cost in terms of speed and time spent processing additional steps.

If operations are done across nodes, it may add significant latency as these nodes are often separated geographically. Any implementation that send additional data across nodes will be disproportionally affected by this and be considerably slower.

There are two distinct versions of Access Control that we will explore in Emerald:

• List-Based Access Control

• Capability-Based Access Control

Each of these versions has their own strengths and weaknesses. List- Based Access Control keeps a list of access permissions in each Resource for Users should be allowed to access it, while in the Capability-Based solution the access permissions reside with the User of the Resource as a proof that they have the right to access the Resource.

The List-Based solution will then have to store permissions within the Resource in some way. This could take the form of a similar structure as the basic Lock solution, though extended to work with multiple Users simultaneously. The Capability-Based solution will attempt to use Emeralds Restrict-To mechanism to create capabilities for Users to store themselves.

These two alternatives will be further explored when we get to the implementation stage described in chapter chapter 6.

For Access Control in Emerald we want to have a solution capable of regulating access an Object and making restricted access possible. We also want the ability to share the Users permissions to the Resource. This is regarded as the basic set of functionality needed to meaningfully test the solution. We also desire to be able to run the solution in a distributed program.

For the List-Based solution we also want a method to be able to remove permissions.

Since the Capability-Based permissions are being tracked by the Users, there is no simple way to remove access, however there may be a way to use proxy Capabilities that are under the control of the User that shared the permission.

(48)

5.4 Authentication

Authentication is central to managing more advances Access Control systems, it performs the authentication of Users and processes so that authorization can be performed for the authenticated users. The authentication is done by an authority that is implicitly trusted in the system.

The objective is to explore ways to create an authority that will enable authentication in an Emerald environment.

Authentication solutions depend on trust, the authority that does the authentication must have the trust of the system, its Resources and Users.

If it is difficult to create or maintin a robust system that Users can trust then that would undermine the systems purpose.

Emerald works well with distributed programs, it will be challenging to create an authorizer that can work in such an environment, especially in a way that can maintain its records across the system in an orderly manner and build an implementation that is able to be trusted.

We might be able to pull out the authorization from the List-Based Access Control solution and base our solution for Authentication on that, the work requires that it be adapted to serve several Resources and work in a distributed environment.

A solution that is able to authenticate Users within an Emerald environment and works in a distributed environment if needed.

5.5 Summary of Exploration

The solutions chosen for implementation in Emerald for Locks will be developed in steps starting with a basic Lock, continue with a granular Lock variant and end with a Proxy-Based Lock. This will enable us to check the functionality between each step.

34

(49)

The solutions chosen for implementation in Emerald for Access Control are the List-Based and Capability-Based versions. When implementing Access Control we will explore the List-Based and Capability-Based versions and compare their differences, and how difficult they are to implement in Emerald. The advantages and disadvantages will be investigated in the Implementation.

Most Access Control schemes use Authentication to some extent as a way to make authorization possible. This makes it possible to build a systems with better security. Authorization logically follows authentication and is used in many types of Access Control. Since Authorization and it’s processes are used as a building block in many Access Control systems, it will be possible to create solutions that share large amount of infrastructure.

Several of the solutions for Access Control overlap with each other in terms of purpose and the way to implement them. As an example, Locks can be extended naturally into working as part of a general Access Control scheme, especially in a computer environment.

Taking the verification of Users out of the Access Control solution itself, might let us set up a way to do Authentication separate from the Resources.

The plan is to start with a simple Lock implementation and build on it to reach a more advanced solution.

The sources explored are as follows: [21] [23] [9] [2] [7] [5] [8] [22] [1] [6]

(50)

36

(51)

Chapter 6

Implementation

6.1 Introduction

In this chapter we will use the theory described in the previous chapter to implement the solutions and explain the challenge of implementation in Emerald.

Further, we will explore several alternative solutions of implementing the types of Access Control we have outlined in earlier chapters.

To gain a better understanding of the requirements, we will take a look at a few use cases of each solution that details the function we expect.

This will give us clear insight into the scope of work required and the functionality that can be ignored to avoid unnecessary complications in our solutions.

There will always be ways to improve or change a solution once you take a function, solution or algorithm from theory to practical implementation, and I wish to express clearly that the purpose of this chapter is primarily to achieve working solutions without excessive focus on the tuning of the performance or optimization of the code itself.

Additionally, I will emphasize that there is no one true way to solve this, so it is likely that it will be an exploration of alternatives, including mutually exclusive solutions.

6.2 Approach

The approach that will be used to define the required functions includes;

• Starting by implementing a basic working solution.

• Evaluating mechanisms in Emerald well suited or ill suited for the implementing solutions.

6.2.1 Emerald-Specific Mechanisms

Before we truly begin I wish to elaborate a bit more on the particular Emerald specific features and mechanisms that we will be employing in search of our solutions.

(52)

6.3 Locks

To create a solution for locking Resources we will look at the use cases to narrow down the functionality we are in need of and the facilities and mechanisms we have available to fulfill the required purpose.

6.3.1 Requirements for Locks

Below is a list of requirements that should be met to be an adequate implementation of Locks, that enable the User to access the Resource in a systematic manner.

• UserObjects should be able to request exclusive access to a Re- sourceObject, thereby locking it

• UserObjects should be able to voluntarily release access to a locked ResourceObject

• UserObjects should be able to ask for access to a ResourceObject that is locked and have the request handled properly without issues to the system

• UserObjects with access to a locked ResourceObject should be able to perform any operation on that ResourceObject while the key to the Lock is valid

• UserObjects should not be able to steal, remove or otherwise impair the usage of Locks that they have not requested access to themselves 6.3.2 Challenges

Given that Emerald operates in a distributed environment we cannot rely on a centralized approach to control access, which means that the solution has to be self-contained with the ResourceObjects themselves and cannot depend on a single authority.

The challenge is implementing the logic for Locks within the Re- sourceObject to enable UserObjects to gain exclusive access in a way that works in a distributed environment.

6.4 Possible solutions

Possible solutions for Locks in the Emerald environment will be mostly concentrated on functionality within the ResourceObjects. The most basic solution works by altering each operation in a ResourceObject with an additional argument containing a key and using that to check for access.

The UserObject also needs a minor alteration to keep and provide a key.

An alternative can be a proxy created by using another object that is made for the strict purpose of redirecting any call on the Resource and

38

(53)

Figure 6.1: Basic object structure for a lock

to return any result. The Lock is released from the lockable object by disconnecting from the proxy making further access through it impossible.

Using such a proxy would necessitate that the proxy conforms to the locked object in the way Emerald conformity describes.

These two alternatives can then be extended with additional functionality such as more granular locking and other novel ways to manage communication to and from the locked object.

6.5 Examples of implementation

We will start by exploring the simplest type of system necessary for creating a functional locking mechanism. Then, we will use that as a basis for implementation to address the challenges and refine the program until we reach a stable solution which fulfils all the requirements for locks listed above. For some examples we will display their mechanisms using UML2 [24].

6.5.1 Basic locking

To implement a basic Lock, a ResourceObject must go through a few simple steps. First, it must include a Lock class designed to take care of most of the logic of handling access to this ResourceObject.

This can be done simply by creating a Lock class within the ResourceO- bject and using it to manage the lock state of the ResourceObject, as shown below:

1 c o n s t Resource <− c l a s s Resource

2 a t t a c h e d var l o c k : Lock <− Lock . c r e a t e //Used t o mediate a c c e s s

3 end Resource

Listing 6.1: Utilizing the lock class

The Lock class exports several operations, which is used within the lockable Object itself and not visible from the outside, these are as follows:

(54)

• setLock, which takes a parameter used to identify the UserObject that locks the Resource

• unsetLock, which will remove access only if the lockee is the one who submit the request

• checkAccess, which tells you if the UserObject submitting the request is allowed to access the Resource

The Resource object then need to implement two operations to expose the locking functionality, both a way to lock and unlock the object.

1 e x p o r t o p e r a t i o n l o c k [ i np ut : any] −> [ r e t : Boolean]

2 r e t <− l o c k . s e t L o c k [ in pu t ]

3 end l o c k

4

5 e x p o r t o p e r a t i o n unlock [ i np ut : any] −> [ r e t : Boolean ]

6 r e t <− l o c k . unsetLock [ in pu t ]

7 end unlock

Listing 6.2: Operations needed to access lockable behavior

Finally each operation exported need two changes to be properly restricted as shown in .

1 e x p o r t o p e r a t i o n incrementOne [ l o c k h o l d e r : a n y , in pu t : I n t e g e r] −> [ r e t : I n t e g e r]

2 a s s e r t l o c k . checkAccess [ l o c k h o l d e r ]

3

4 r e t <− in pu t = (i n t e g e r + 1 )

5 end incrementOne

Listing 6.3: Operations shall not allow unrestricted access

The lockholder variable will hold a reference to the object that wishes to access the Resource and will be checked through the assert, if it does not pass muster it will trigger a failure state and any further execution within this operation is halted. From the UserObject that wishes to use the ResourceObject it can be expressed such:

1 var r e s o u r c e O b j e c t : Resource <− Resource . c r e a t e

2

3 r e s o u r c e O b j e c t . l o c k [ s e l f ]

4

5 r e s o u r c e O b j e c t . incrementOne [ s e l f , 1 0 0 ]

6

7 r e s o u r c e O b j e c t . unlock [ s e l f ]

Listing 6.4: Usage of a lockable Object

40

Exploring Implementations of Access Control in the Emerald Programming Language

Exploring Implementations of Access Control in the Emerald

Programming Language

Eirik Fjellheim Andersen

Thesis submitted for the degree of

Master in Informatics: Programming and Networks 60 credits

Faculty of mathematics and natural sciences

UNIVERSITY OF OSLO

Exploring Implementations of Access Control in the Emerald

Programming Language

Exploring Implementations of Access Control in the Emerald Programming Language

Abstract

Acknowledgements

Contents

Part I

Introduction

Chapter 1

Introduction

1.1 General

1.2 Motivation

1.3 Problem Statement

1.4 Goal

1.5 Approach

1.6 Work done

1.7 Evaluation

1.8 Results

1.9 Contributions

1.10 Conclusion

1.11 Outline

Chapter 2

Definitions

2.1 General Definitions

2.2 Programming Definitions

Part II

Earlier Work and Background

Chapter 3

Background

3.1 Introduction

3.2 Historic perspective

3.3 Basic Access Control

3.4 Advanced Access Control

3.5 Authentication

3.6 Summary

Chapter 4

The Emerald Programming Language

4.1 Introduction to Emerald

4.2 Conformity of types

4.3 Emeralds Restrict-To mechanism

4.4 Emerald Classes

4.5 Nodes

4.6 Additional reading

4.7 Summary

Part III

Building Solutions

Chapter 5

Exploration

5.1 Introduction

5.2 Locks

5.3 Access Control Methods

5.4 Authentication

5.5 Summary of Exploration

Chapter 6

Implementation

6.1 Introduction

6.2 Approach

6.3 Locks

6.4 Possible solutions

6.5 Examples of implementation