Access Road 0.7.3
Introduction to Access Road


The simulations | The graphical user interface

The tutorials | The limitations | The design | The reliability



The Access Road software is a universal simulator of access controls that is intended to improve design and auditing of IT security.

Access Road simulates components, behaviors and access controls

By design, Access Road uses a large set of concepts for modeling the components and the access controls. It may simulate many real systems, including their structural properties and behaviors, and their standard and non-standard components with the relevant rights.

The main improvement of the last release 0.7.3 is to manage the session user identity through varied connected software. This release includes the following features:

  • this release models a software using the account of its caller, in a local or distant user session starting with any kind of authentication, to apply its own access controls on its components,

  • it models the active and passive system components of an application in an operating system, improving the concepts of static and dynamic roots (like the Ubuntu files which contain a MySQL table),

  • it simulates the general behavior of the call and data paths from a first modeled software ensuring the initial user session, through a second modeled software and its own access controls, and ended with the components of a third modeled software having also its own access controls,

  • to demonstrate these features, this release defines how an Ubuntu program, like the MySQL server, is a set of Ubuntu components interacting with the child ACS which models this MySQL server,

  • short user-defined comments may be added to a full view.

The release 0.7.3 extends the concept of transfered Account/Group context. It manages these transfers between software with the new concepts of communication end point, data exchange point, entry context switch and exit context switch. These concepts offer a first model for managing the IP addresses. They ensure the continuity/deletion/replacement of the user identity over the data exchanges through a network. They are also applied between the processes and the applications of an operating system. The new features of the release 0.7.3 are explained mainly in the third tutorial.

Access Road 0.7 provides the simulation of two great software and one theoretical application for learning purpose:

  • as an example of operating system, the GNU/Linux Ubuntu® 8.04 access controls are simulated with the file system and the authorization system; this covers, in an ACS addon (new in 0.7), the User-Group-Other GNU/Linux rights including the inherited rights from the parents, some GNU/Linux kernel capabilities, and the Ubuntu authorizations on system resources,

  • as an example of DBMS, the MySQL Server® 5 access controls are simulated (new in 0.7); this covers the structure of components, the MySQL privileges, the priority rules among the privileges and the privileges inheritance,

  • at the application level, a typical large application which follows the Role-Based Access Control model; this covers the tree of functional roles, the application transactions, and the ACLs with granting and denying rights.

To specify the structure and the behavior of a software in a new ACS, two ways are proposed without coding: (1) through a smooth derivation from a given simulation, by changing a limited set of variables, (2) by entering all the properties of the simulation by hand. The ACS components have to be defined by hand if Access Road does not offer an automated generation like for Ubuntu or MySQL server. Such generation allows to delete or update the ACS components if they are not mandatory.

Access Road 0.7 is able to simulate, right now, a certain variety of application software. The RBAC model is a good representative of the application needs. For the other types of software (system software, network software...), the access control functions and the structure are often more complex. Every software has to be studied thoroughly to evaluate the Access Road ability to simulate it. The source of the data is never the algorithms or the code of the software to simulate, but its official description in the user documentation and its behavior, seeing from an user point of view. The current 0.7 version has still a long way to go before being able to simulate the thousand of important software in IT systems.

The graphical user interface

The graphical user interface is standardized, easy to use and versatile. It facilitates both simple and complex works over all the simulations to handle. It allows the user to study the details of a complex structure... or the final compliance with a general security rule. It allows him to work on large texts which explain a simulation... or on a diagram to catch a result in a single look.

The GUI may be customized for a given ACS, but mainly on the properties the beamer displays. By this way, when the user learns the GUI for one ACS, he masters it for all. He may then concentrate his efforts on the behavior of each modeled software. Newbies may easily use Access Road after the creation of a simulation by an inner feature, or by an advanced user.

The GUI uses an object-oriented framework including multiple windows, varied kinds of diagrams and textual representations. The mouse has to use only the left clicking. This is straightforward because the GUI automatically adapts the open windows to the new selected object. All the simulations start with the creation of an Access Control System (ACS) to model a given software. The main features of the graphical user interface are listed hereafter:

  • the explorer shows in a specific window the structure, as a tree, of the open Access Control System (or ACS), the open views and the generic rights,

  • the beamer window allows to see and to update the properties of a modeled object, with all the update constraints coming down from the ACS policy, and it manages also the specific properties from an ACS addon,

  • the information system window displays the tree of all the ACS and the passive nodes the programs knows, including their parent/child relations (new in 0.7),

  • the sketcher window shows quickly the very near objects of any modeled object, that is, its direct rights users and access targets, with the relevant rights,

  • the user-defined full views for rights simulation, containing from 0 to 48 objects in each view, to search all the direct and indirect access paths between the view objects, and to display the paths in the form of a diagram and a text,

  • the user-defined NoMore-NoLess views for the security policy compliance, to display in a diagram, and for one access target, if a set of rights users fulfills the maximum/minimum allowed rights on this target,

  • the export/import functions to export images and texts from Access Road in any external document, and to exchange ACS models between different desktop computers.

Exchanging ACS models may be useful for the internal users in a company. In the future, we hope it will allow to set a public catalog of shared ACS made both by the developers and the non-developer users.

The Access Road files of the releases 0.6.x cannot be open in this 0.7 version. The release 0.7.3 ensures a backward compatibility for all the 0.7.x files.





About Access Road



One-hour tutorial for learning access controls

Two-hours tutorial for designing access controls

Three-hours tutorial for verifying access controls

Why Access Road is unique

Glossary


The tutorials

Three basic tutorials are the getting-started documentation. They have been fully reviewed for the release 0.7.3. The tutorials provide a smooth learning curve to everyone. There is no requisite about the skills to have. The tutorials use a balanced approach to learn both the Access Road core platform, and the use of a given-software simulation, even if you do not know this software. By the way of a simulated GNU/Linux Ubuntu® and a simulated MySQL Server®, they demonstrate how the generic functions support the specific features of a given simulation. The tutorials introduce Access Road from 3 points of view listed hereinafter:

  • an one-hour tutorial for learning the access controls of a simulated GNU/Linux Ubuntu®, and for using the four main tools: the explorer, the beamer, the IS structure and the sketcher; it is a 22-pages printable document,

  • a two-hours tutorial for knowing the main ACS properties, for understanding the design of access controls into MySQL Server®, and for learning how to use the Access Road full view; it is a 28-pages printable document,

  • a two-hours tutorial for verifying in a theoretical Role-Based-Access-Control application, the access controls compliance with the security policy, for learning the NoMore-NoLess view, the simulation of the data and call exchanges, and the ACS import/export functions; it is a 25-pages printable document.

It is recommended to follow these 3 tutorials in their order of presentation. Nonetheless, the user interface is so intuitive that one may start directly to work with. When a new concept appears, the 23-pages glossary of Access Road defines and links the varied concepts and terms. Last but not least, there are some specific tutorials for the ACS add-ons GNU/Linux Ubuntu and MySQL Server.

Enjoy Access Road! We hope to bring to you a powerful, user-friendly, reliable, efficient and scalable program. Don't hesitate to tell us your personal opinion about both the concept and the tool.

What Access Road 0.7 does not do

This section should be ridden after the tutorials. The generic features have the following limitations:

  • The authentication services, like the password checking, are not covered by Access Road. They are before the access controls, and authentication is a separate security function. On the other hand, Access Road has to simulate how the legitimate use of a given user account is a data to be transferred across the software and the server platforms to become the base of some access controls.

  • The logical access controls of the software are modeled, not the organization of a company. For instance, if two users have one common pair of IT user account and password, this is not visible by the logical access controls.

  • Access control simulation is about what it is really possible to do, not what is the experience of an administrator using the simulated software. The GUI of the simulated software is not simulated by Access Road. On the other hand, it is often a secondary objective to help the user to find in Access Road the usual concepts of the simulated software. For instance, the SQL GRANT statements are not exactly simulated, although the MySQL access controls are created through them. There is a precise consistency between the space of the MySQL GRANT statements, and the commands Access Road handles to simulate the MySQL Server. Moreover, the Access Road GUI mimics the GRANT statement to present the current state of the MySQL Server access controls, in so-called 'primary rights'. But this indeed is not a full simulation of the GRANT commands.

  • There is no ability to import the state (components, general variables, rights) of a simulated software from a real instance of the software, nor to export a simulated state into a true instance. Generally speaking, importation and exportation are more easy to do than the simulation, for a given software. They are planned for future versions. We think that this feature is the key to ensure the success of this project. Nonetheless, the development of the universal platform is the first mandatory step to succeed, because we have to demonstrate first the Access Road concept.

  • Access Road does not handle some 'false' access controls. For instance, when a developer accessing a PostgreSQL database uses the command 'SET ROLE' to change dynamically the set of rights PostgreSQL attributes to its connection, this is not access control, but simply a coding practice. In fact, the program does have the rights of all the set of roles PostgreSQL allows this connected user to take. In such a case, an Access Road simulation of PostgreSQL would cover the rights from all this set of roles as a whole, just like they are offered to this connected PostgreSQL user.

  • The administrative rights, that are the rights to change the current rights, are modeled but their application to change the current rights is not provided. It is not possible to aggregate the access controls result of two distinct states of the base, to simulate a sequence of states.

The GNU/Linux Ubuntu simulation has the following limitations:

  • the GNU/Linux kernel capabilities, which are a special form of access control on the OS resources, are not fully simulated,

  • the POSIX ACLs are not modeled,

  • the GNU/Linux network system and the Netfilter firewall are not modeled.

The MySQL Server simulation has the following limitations:

  • the security-related mysqld options are not managed,

  • the host and base names cannot include more than one wild card,

  • the blank user names are forbidden,

  • for a host value specified as an IP address, there is no handling of the netmask.



About Access Road



One-hour tutorial for learning access controls

Two-hours tutorial for designing access controls

Three-hours tutorial for verifying access controls

Why Access Road is unique

Glossary


The design

We think access control simulation is a worldwide innovation. We are proud to bring in it as a great free software. Access Road 0.7 is the result of more than 5 person-years of work to search the best design solutions, and to develop a code which is fully original. There is no integration of external code libraries, nor software-generated code.

The main innovation has been to study a core platform for handling all the access controls, able to be configured for simulating the access controls of a given software. The second innovation has been to present to the user, the full complexity of rights in, as far as possible, simple, generic and varied points of view, while a limited customization offers the best possible explanation about each simulation. The third innovation is an unique in-memory object-oriented database management system, which provides great performance, integrated integrity controls, extensibility and scalability.

The Access Road design is driven by the following principles:

  • to model first the objects on which access control applies, then the access controls, and for that, use some concepts as UserID, GroupID, Resource, Directory, Access Control Lists, User-Group-Other rights as in GNU/Linux®, Group hierarchy as in a RBAC application, granting and denying rights, rights hierarchy, rights inheritance...

  • to model the structure of each specific software to simulate it as one or several 'Access Control System' (or ACS) in Access Road, and to model the internal structural constraints on the key properties of each ACS object,

  • to use 8 architectural patterns, like the access path search pattern and the ACS add-ons pattern, to master the software re-usability, testability, performance and extensibility,

  • to design the rights simulator for detecting all the authorized paths between any given couple (rights user, access target) from any ACS, and for detecting all the structural links for any couple of objects, like the owning relation from an account to a file,

  • to show the rights simulation into complementary diagram and text, where the diagram offers a simplified and visual result, but without never being a caricature that distorts important things, while the text explains in details all the results in a standardized form into which an ACS add-on may insert its own terms,

  • to update the simulations on the fly, at each user change on any object property which influences the current right simulations,

  • to set multi-threading for the access paths search, letting the user interacts with the program during the large searches (new in 0.7); on the other hand, most of the searches are done in a period of less than one second, on a medium-size desktop computer,

  • to design the ACS add-ons for facilitating the extension of the Access Road simulations with a minimum effort of Java coding, offering a great versatility in the choice of the generic features to adapt to a new simulation (new in 0.7).

An ACS contains a catalog of components, so-called ACSObjects, which are registered into the ACS at their creation. Each ACSObject class implements a key concept to model. The relation ACS/ACSObject is strong. Deleting an ACS deletes all its ACSObjects. The catalog of ACS components is intended to model the software the ACS simulates. On the other hand, one given ACS has not to handle all the kinds of ACS component. Most of the ACS use only a selected part of them. There are 8 main types of ACSObject Access Road implements: UserID, GroupID, Resource, Directory, VirtualFolder, Actor, ExchangePoint (new in 0.7.3) and ContextSwitch (new in 0.7.3). In addition to the Account/Group rights in a Resource, there are 4 main types of rights: AclEntry, PrivilegeForLinks, PrivilegeForType and white/black lists for EndPoint (new in 0.7.3). This model produces 24 structural boolean properties, to set the concepts a generic ACS manages. It handles about 100 properties to drive the behavior of its ACSObjects.


The reliability

The 0.7 version is a beta version, but it is workable and reliable. It is able to help the user for complex works. Errors should be from the code, of course, but also from the specification of a given software simulation, or from any user misunderstanding because the results may be rather complex. The overall reliability of Access Road is based on the following principles, trying to cover the main issues:

  • the object-oriented database system is isolated from the other code packages, and its code is thoroughly tested,

  • this database system ensures all the integrity controls, coming down both from the general model and the software simulation model,

  • the specification of a given software simulation is done, as far as possible, through a set of properties the user may consult and study at any time, and this includes the ACS addon properties,

  • the code for the generic access paths search is mainly structured by the ACS properties to handle; it is tested through a large set of generic ACS and ACS add-ons to cover most of the ACS properties space,

  • the most difficult errors is when the context of use of a method may change strongly, or when a method does things beyond its contract. The usual catalog of unit and integration tests is never sufficient to cover all these complex cases. This is still more true for a framework. The best way is to use different contexts of use for each method to test, so that most of the bugs appear. The Access Road way of testing is to test both the results, the call paths among the methods, and the changes of the inner data in a class or a method. Nonetheless, such a framework has to be tried by numerous users in varied contexts to be fully reliable. This is why Access Road 0.7.1 is considered as a beta version, although it is quite stable.

  • the access paths search code is also tested by the comparison of several independently-coded algorithms (but this is no parallel programming) to search for the 2-nodes paths, the 3-nodes paths and the more-than-3-nodes paths,

  • the user updating is controlled, and each refusal by the program is explained to the user, with the true context of the ACS and the implied simulations,

  • the simulated access paths between two modeled objects are explained in details in a generated text, to avoid, as far as possible, any misunderstanding of the results,

  • the specific behavior of an ACS is explained into several beamer ACS tabs ('Rules', 'See Why') and by a dedicated documentation.

The simulations | The graphical user interface

The tutorials | The limitations | The design | The reliability


®All trademarks are property of their respective holders. Copyright ACCBEE – 12 February 2013



About Access Road



One-hour tutorial for learning access controls

Two-hours tutorial for designing access controls

Three-hours tutorial for verifying access controls

Why Access Road is unique

Glossary