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
tu torials
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
|