Access
Road 0.7.3 Learning access controls
|
|
Creating
ACS | Explorer | IS
Structure | Beamer
Editing
a list | Sketcher | Umask
This
getting-started one-hour tutorial is for learning the basic
commands of Access Road. It takes the example of a simulated
GNU/Linux®
Ubuntu® software to show the handling of the umask feature.
This first tutorial
should be ridden by each Access Road user. The approach is to
discover together the Access Road generic features and a given
simulation. This tutorial explains the following actions:
creating
an Access Control System (ACS) which simulates a GNU/Linux®
Ubuntu®
operating system,
using
the explorer for showing the structure of the ACS,
using
the IS structure to display the inter-ACS relations,
using
the beamer for reading and editing the properties of any
component,
using
the sketcher to see the simplest and direct rights around an
object,
using
all these tools to study the concept of umask in GNU/Linux®
Ubuntu® ,
as an example of the new learning capacity with Access Road.
The best way is to read
this tutorial twice: first as a simple reading, and then to
operate on Access Road. This is rarely a waste of time. The
duration is estimated at one hour.
You may choose to stop
the tutorial before its end. How to launch Access Road is
described in the 'README.txt' file for the executable. How to
exit Access Road and save the current configuration is explained
at the end of this tutorial.
Creating
an Access Control System
Run the Access Road
program. Close the central information box. To follow this
tutorial, close each open ACS, if any, through the command File →
Close (select first the ACS node under the node 'Open Access
Control Systems' in the explorer).
You should have the main
Access Road window, without any internal window. Some window
border colors and title policies may change when you run it on
varied operating systems, but most of the user interface is the
same.
The main menu is very
simple. The active fields to operate with are generally included
into the internal windows like the explorer window. To create the
out-of-the-box simulation of a GNU/Linux®
Ubuntu®,
select in the main menu the command File → New → 'New
Access Control system'. This dialog opens:
Enter the name 'IO'
for the ACS IS, the name 'tubun' for the new ACS, select the
second choice 'Linux Ubuntu 8.04', and click 'OK'.
This question appears
(see the following image). Click 'Yes' then 'OK' to create
the IS physical node which will be the parent of the Linux®
system in its information system 'IO'. This dialog 'NEW
COMPONENT' appears. Enter the name 'one', click 'physical' to
create a physical node, then on 'OK'.
The question 'Do you
want to create another component' appears. Click 'No' then
'OK'.
Note: if you answer
'Yes', it is possible to create one or several physical or
logical IS nodes under 'one' and above the ACS 'tubun' node.
That's all to create the
ACS 'tubun'! Access Road makes the job. You should see the
opening of two internal windows: the explorer at the top left,
and the beamer at the top right.
The explorer is shown
there after a click to see the children of the ACS node 'tubun'.
Generally speaking, any
simulated software in Access Road is modeled as an 'Access
Control System' (ACS). An ACS has to be opened to operate on
it. A closed ACS is never implied in the search of the access
paths, even if it is indeed a support for true execution and data
paths. Opening and closing an ACS is a very simple way to see its
role from the point of view of its environment.
All the searches about
the access paths are done into so-called Access Road views.
They will be studied in the next tutorials.
The third and last
first-level node in the explorer is for the generic rights.
They are always visible (they are not opened and closed). These
rights are a description of a generic network of rights, as a
catalog of standard rights any ACS may use. An ACS may have a set
of specific rights, named ACS rights. Each ACS right is
associated to one generic right, to ensure the comparisons and
the translations between the rights.
|
About
Access Road
Introduction
to Access Road
Two-hours
tutorial for designing access controls
Three-hours
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
The explorer
The explorer displays the structure of all the open objects in
Access Road. It is
always visible, while all the other internal windows may be
opened and closed. The user opens and closes the ACS and the
views through the menu, after a selection in the explorer. To
save, close or open the ACS 'tubun', the
user uses in the main menu one
of these 3 commands: File → Save, File
→ Close or File →
Open → Open Access Control System.
For an ACS, the explorer
may display varied kinds of components. The nature of the ACS
components, and then the names of the third-level nodes under the
node 'tubun', depends on the nature of the ACS, in other words,
of the nature of the simulated software. The explorer comments
most of the third-level nodes under an ACS as an access
target or a right
user. A right user
is simply an entity which has the potential ability to access to
an access target, if the ACS allows it. The main type of right
user is EligibleParty,
which has several subtypes in Access Road. The most common type
of access target is Resource,
which has also several subtypes.
An executable program into an operating system is an example of
right user being also an access target. Such an entity is modeled
as an Actor
into Access Road. Every
software component which has both a behavior of right user and a
behavior of access target will be modeled by Access Road as an
Actor. Of course, there are varied kind of Actors in Access Road,
like for instance the Executable which is a proper concept of the
'Ubuntu' ACS. It is important to know this generic vocabulary,
because it is used in Access Road to describe all the software
simulations, whatever their properties. Introducing the generic
vocabulary is an objective of the tutorials.
The explorer displays
the main components of an an ACS or a view. For the ACS 'Ubuntu',
there are the followings:
the
Resources like a directory or a file,
the
UserID (kind of EligibleParty) like a personal account
'tom',
the
GroupID (kind of EligibleParty) like the group 'tom',
the
AclEntries to deliver rights on a target to a right user,
the
proper ACS rights of 'tubun',
the
external components of 'tubun' do not belong to it.
Coming from other open ACS, they are displayed in two separate
nodes for the Resources and the EligibleParties.
For the moment, there is no AclEntry. The specific rights of a
GNU/Linux®
are displayed. Some ACS rights are used for accessing the file
system, like the well-known 'r' to read a file. Each time it is
possible, the ACS right reuses the standard name in GNU/Linux®.
However, it may be necessary to create specific ACS rights to
offer a complete model of the software. Some rights, like
'authorize', are reserved to the authorization groups. This ACS
right is not always known by a GNU/Linux®
administrator, since authorizations are not implemented by all
the Linux distribution.
To keep an eye on the ACS components, it is possible to open a
dedicated window for one open ACS. Select the ACS in the
explorer, then use the command Window → View diagram or
ACS tree. The tree of the ACS components is displayed in a
new internal window, at the bottom right coin. Each window has an
unique and clear title, that is for this window 'ACS + name of
the ACS'. The displayed ACS tree is exactly like into the
explorer. However, selecting a tree node does not operate.
The subACS
To explore the 'tubun'
default components, click the node 'Resources (access target)'
to open it, then open the first child node '<files_tree>'.
The first level of file directories appears. An 'Ubuntu' ACS has
two independent subACS named 'authorization' and 'capability'. A
subACS is a subset of components and rights having a specific
logic. This is added to the main set of components in the ACS,
like the file system and the general UserIDs in a GNU/Linux®
Ubuntu®.
These subACS are not explained in this getting-started tutorial.
The
point here is a subACS may have a specific subtree of resources,
like 'authorization' there, and/or a specific set of GroupIDs.
Click the node 'GroupID (right user)' to open it. The
explorer shows the first two children 'authorization_subacs' and
'capability_subacs', which are two separated sets of groups. As
you see, the subACS 'capability' has a set of GroupIDs, but no
set of Resources.
|
About
Access Road
Introduction
to Access Road
Two-hours
tutorial for designing access controls
Three-hours
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
The IS Structure
An ACS belongs to an
Information System. The 'IS structure' is the internal window to
display the tree of all the information systems, with theirs
children nodes. Select in the main menu the command Window →
IS Structure (or Ctrl+i). The 'IS Structure' window appears.
It has two parts: at the top, four properties are displayed, and
a tree of nodes is set in a second part. The last node in the
tree is for the information system 'IO' we have just created for
the ACS 'tubun'.
Click the node 'IO',
then on its children 'one' and 'tubun' to open them. The
result is this following window, where the ACS 'tubun' and its
two subACS are visible. It is possible to create an IS node like
'one' only at the creation of an ACS. The creation procedure
allows to set a sequence of parent IS nodes under which the ACS
is created.

At the opening, the 'IS structure' window shows the properties of
the first child under the root: 'IPv6'. The property 'Type' tells
it is an information system, like each direct child of the root.
The property 'Open' tells it is closed.
Click 'IS Structure',
the root node of the tree. A
list named 'ACS add-ons' is displayed at the top of the window.
The list contains two items: 'Editor: Accbee - AcsAddon: MySQL '
and 'Editor: Accbee - AcsAddon: Ubuntu'. They are the ACS add-ons
Access Road has detected during its opening procedure, among the
executable files under its working directory. The creation of a
'Ubuntu' ACS is proposed in the dialog for creating ACS, because
Access Road has registered the relevant ACS add-on. Of course,
one may uses this 'Ubuntu' model to simulate another GNU/Linux®
distribution, but it is strongly
recommended to check the differences, for instance about the
subACS 'capability'.
'IPv6' and 'IPv4' are reserved IS names to model the two IP
address spaces as information systems. A node in the IPv4 IS must
have an IPv4 format, that is, the first 4 name components, after
'IPv4', must be a number between 0 and 256. For the IPv4 address
'192.168.50.4', '192' has to be a direct child of the node
'IPv4', '168' is a direct child of '192', and so on. As for the
ACS nodes, the user cannot create directly an IP node into the
'IS Structure' window, nor change a property value. The 2 IP
information systems are used to set the network addresses of the
ACS ExchangePoints and ContextSwitches. Updating an ExchangePoint
or a ContextSwitch may produce the change of an IP node. These
features are presented in a next tutorial.
Click 'tubun', the
node under 'one'. The
properties of the node 'tubun' are displayed in 3 tabs named
'Basic', 'General' and 'Links'. Most of the properties are for
future use. The property 'Tied child' is set at 'false'. This
means this ACS is not automatically opened when its parent is
opened. This property is set at 'true' to simulate the running of
an application its operating system launches at its proper
starting. The two Resource subACS of 'tubun' are visible under
its node. On the other hand, the GroupID subACS of an ACS is
never displayed by the IS structure.
Clicking all the path nodes, from the tree node 'IO' to the tree
node 'authorization', changes the tab 'Basic' at the top of the
window. This action shows that every node is open, while the
types change from the value 'information system' to 'subACS'.
Creating or opening an ACS in Access Road opens all its parent
nodes in its information system. If it is not into 'IPv4' and
'IPv6', an information system node is closed when it has no open
ACS as direct or indirect child. When an IS structure node is
closed, the color of its icon changes. For an ACS having a proper
icon, like 'Ubuntu', closing the ACS changes the icon to the
default one, and opening the ACS restores its proper icon.
Without proper icon, the IS tree always displays the ACS node
with the default icon.
Access Road
is designed to handle thousands of closed ACS, and up to one
hundred of open ACS. The IS structure gives an overview on the
static relations between all the ACS, even if they are closed.
The IS structure window closing, like any internal window, is get
by clicking the cross, at the top of the window. Click the
cross now. Most of the windows may also be iconified or
enlarged by the user. The location and the size of a window may
be changed with the mouse. At the Access Road saving, all the
open window locations and sizes are saved, to be restored at the
next Access Road launch. When a window is reopened during an
Access Road session, its last saved location and position are
restored.
|
|
The beamer
The beamer should be
always visible, but it may be iconified by the user. It displays
the structure and the properties of a selected open object in the
explorer: an ACS, any ACS object, view or generic right. The
beamer shows the current values in the Access Road base. The
beamer is the unique window to edit the properties of an object.
It is the unique window to read a property if it is not about the
IS Structure. The property changes in the beamer are
propagated to the other open windows, and sometimes to other
displayed properties in the beamer.
The only exception about
the objects editing is for the global handling of ACS and views,
that is to create, close, open them in the database, save and
import them to/from files, and remove them from the IS structure.
These actions are reserved to the Access Road main menu, where
all the command names are clear. However, adding or removing a
component to an ACS or a view is also the responsibility of the
beamer. Like the explorer, the beamer displays only the relevant
properties of each object, and the beamer allows to navigate
among the open objects.
To explore the 'tubun'
default components,click in the explorer on the node 'tubun',
if it is not already done (it is selected if you have followed
strictly this tutorial). When the explorer is selecting the node
'tubun', the beamer is displaying all the properties of this ACS
in a set of 13 tabs. GNU/Linux®
Ubuntu® is
simulated in an ACS add-on. There is some specific code to
complete the generic features of Access Road. The ACS add-on
defines the main structure and the behavior to the ACS 'tubun'.
ACS is indeed the most complex concept Access Road models. The
number of visible ACS properties is about 60, but several ones
are rather complex maps (key, value). The good news is the Access
Road user has generally not to understand all of them. They
explain the Linux Ubuntu behavior when one wants to look at the
details, for instance to derive a new ACS from an old one. But
they are not necessary to design a given Ubuntu instance. After
all, Access Road simulates 'Ubuntu' for you...
All
the Access Road names are made of components with the pattern '::
' as separator. This is also true for simulating a Linux Ubuntu,
for which the internal separator in a file name is '/'. In
the visible tab 'General' of the beamer, let's see some first
properties of the ACS 'tubun':
The
ACS name has a special structure which is derived from the
location of the ACS in its information system: 'IO' is the name
of the IS, and 'one' is the name of the physical node which is
the parent of 'tubun' (you may see 'one' as a computer).
The
ACS Comment contains now the 'Creation date' of the ACS. You may
add any comment to this Comment white field: click it, enter
your text before or after the current text, and then press Enter
to edit the value. A
whitespace is added at the end of your text, when the new value
is registered into the Access Road base (but not saved).
Generally speaking, the beamer displays exactly the internal
state of the base in memory, at any time.
The
ACS type tells it is a Linux Ubuntu simulation, and it is also
visible through the name 'Ubuntu' of the ACS add-on. (New in
0.7.1) The policy checksum of the ACS depends on the ACS
structure, the subACS, the types policy and the rights policy.
All these properties are set at the creation of the ACS, and
they are immutable. The policy checksum helps to detect an ACS
that has been derived from another one. If the new ACS
properties have been changed for some of these key properties,
the checksum allows to see it, while there is no change of the
ACS type.
When a field is in white
into the beamer, it may be edited directly by the user. When the
field is in yellow, the editing is forbidden by Access Road. The
last two properties show clearly the limits of the ACS add-on
Ubuntu. The property 'Incomplete behavior' is true, because the
POSIX ACL are not simulated, among other things. Even if the
property is set 'false' for another ACS, this choice is done by
design, and it does not take account of the Access Road bugs. The
property 'Incomplete objects list' is also true, because the
complete Ubuntu file system, including all its components, is not
created into 'tubun'. This ACS add-on creates the first level of
file directories, and it is up to the user to complete them.
In the explorer click
the directory 'home', under the node '<files_tree>', to
explore the 'tubun' default components. In the tab 'General', the
name of this directory shows it is simply derived from its
location in its ACS. For
the object 'home', 'General' contains 5 first standard
properties: name of the object, its IS, its ACS, its comment and
its type. Some
property are displayed with one or several buttons, like 'ACS'
with a 'See' button.
Click
the 'See' button of the 'ACS' property. The
explorer selects the 'tubun' node, and the beamer switches to
display the properties of 'tubun'. Through the 'See' buttons, the
beamer allows to navigate
among the objects of the base. It
displays here the same tab 'General' because it exists both for
'home' and 'tubun'. If 'home' is in the beamer with for instance
the tab 'As Directory', and if another directory is selected for
the beamer, the same tab 'As Directory' will be shown into the
beamer for the new selected object. This feature facilitates the
comparison between objects.
The
beamer follows the hierarchical suite of concepts which define
the object. In
the explorer, click the directory 'home'.
This directory returns into the beamer, with 4 first tabs coming
from its nature of Resource. There is a final tab coming from its
nature of Directory is named 'As Directory'. If you select an
Actor, because an Actor is also s Resource, the beamer would
display it with the same 4 first tabs, followed by the
Actor-specific tabs, and so on. This object-oriented presentation
into the beamer facilitates the comparison between objects and
between ACS (See the glossary to
go further). After
a few practice, the beamer becomes the easiest way to remember
the nature of a selected object in any ACS. It shortens the
learning curve for a new kind of ACS into Access Road.
The
beamer may use a complex policy to NOT display some properties of
an object. The first case is when an ACS does not manage a
structural property, like the privileges. Because the ACS
'Ubuntu' does not manage them, there is no 'Privileges' tab for
an object from this kind of ACS. To see the second case, click
in the explorer the node ' tubun:: <files_tree>:: home::
jerry:: d_jerry:: e_jerry:: '. Following the object-oriented
presentation, the two last tabs in the beamer are about its
nature of Actor and Executable. The second tab 'Alias' comes from
its nature of Resource, while it was not visible for the
directory 'home'. The Alias properties are never useful to model
an Ubuntu directory. In the same way, there is also a policy to
display or not the tab 'ACL', as it is visible for 'e_jerry'. An
ACS may handle a policy to say to the beamer: 'no displaying of
this tab for most of my objects, excepted for...'. This
adaptation presentation into the beamer simplifies the reading by
the Access Road user.
Click
the beamer back button:
this is the yellow/Grey arrow on the top left of the beamer, just
under the beamer title. The beamer returns to the previous
object, that is 'home'. In the 'General' tab, the fifth value
'Access Target Type' may be updated by the user, by the way of a
list of proposed values. Let's try to change the 'home' type.
Click
the little black triangle, at right of the 'Access Target Type'
property. A list
appears. Click one of 3 proposed values. Access
Road displays the error message: 'home has a type which forbids a
type editing.'. This illustrates how the beamer is designed. It
displays the properties in a standardized way, like there the
types in the selection list, but this does not mean all the
values are possible. There are several
levels of selection and control, for the new value of a property:
First,
from the 'home' ACS policy ('tubun' there) or from a
preprocessing depending on the object type, Access Road defines
a first list of the allowed values, and this list is displayed
by the beamer,
Second,
after the user choice, the selection is send to the Access Road
base which checks the new value from the ACS integrity rules.
Here, the current type '<byAcsCreator>' of 'home' means
that this object has been created at the creation of the ACS.
This type is a standard one, and it can never be changed by the
user. This integrity rule avoids to alter the files system. An
'Ubuntu' ACS does have a 'home' directory.
All the efforts have
been done to define powerful generic integrity rules, covering
all the Access Road objects, and to complete them with specific
integrity rules for a given kind of ACS. These integrity rules
are very versatile and powerful. The aim is to ensure the
consistency of the simulation for a software. These rules limit
the risk of error in a simulation, due to a user command or a
program command from outside the Access Road base. The rules
about the object types will be seen at the end of this tutorial.
|
|
Editing a list
We
will see now the handling of buttons and lists in the beamer. For
the user, the beamer is
the only way to create some objects in the ACS and the views.
It is also useful to
link some objects together. Click
the 'As Directory' tab into the beamer window. This
image shows the state of the beamer:

The tab 'As Directory'
appears in the beamer only for a directory, like 'home' there.
The type of 'home' is also put into the title of the beamer. The
property 'Children' is associated to a list and 3 buttons. The
list displays the current children with their Access Road full
names. The full name of an ACS object starts with the ACS name.
Each directory child is a Resource. For all the Resources,
the name contains the path of the indirect parents.
The list is in yellow
because it cannot be directly changed. The buttons play this
role. They are listed hereafter:
'See'
lets the user to select in the explorer the current selected
value in the beamer list, and this means of course that 'home'
would be no more displayed.
'New'
allows to create a new object and to add it in the list, by the
way of an updating of the base. The type of the object to create
is of course derived from the current property the beamer
displays: 'Children' there.
'Delete'
is the inverse operation, to delete one or several selected
items in the list, by the way of an updating of the base.
The 'New' button always
creates the object with the right type. In the context of this
property, the ACS 'tubun' manages varied children. For helping
the user to avoid a wrong creation, clicking the button 'New'
selects the allowed types into the relevant ACS. This is always
true, whatever the displayed object and the property in the
beamer, like 'home'/'Children' here. However, like the 'Access
Target Type' property above, a selected type for a creation may
still be rejected by the base at the second step.
Click 'New'. A
dialog box appears at the center of the Access Road window, to
enter the main properties of a new 'home' child. The ACS
configuration of 'tubun' specifies that it handles 6 types of
resources:

'Resource' is the basic
type. 'Directory' is a Resource having children. 'Actor' is a
Resource being a right user. 'ExchangePoint' and 'ContextSwitch'
will be studied further. These 5 types are generic, and they are
defined in the glossary.
'Executable' is specific to the ACS add-on 'Ubuntu', as a type of
Actor having complementary properties.
Select the case
'Directory' then click 'OK'. The following dialog box 'Create
a new Directory' appears.

Enter the name 'one', do not enter any 'Account', select
'directory' as the 'Access Target Type' (not '<immutable>
directory'), then click 'OK'. It is possible to enter these
properties without the mouse, from the computer keyboard using
the keys 'Tab' (or '→'), '↓', '↑', and 'Enter'.
The new directory
'one' is created in the base. The list of the 'home' children
is updated both in the explorer and the beamer. The 'Children'
list is resized in the beamer, to take account of this new item.
Like the 'Access Target
Type' property, the Access Road base checks the new child from
the ACS integrity rules. There is a rule about the authorized
types for the children of a directory having a given type. If the
user try to create a kind of forbidden object under 'home',
whatever the properties the user enters, the ACS will return an
error message like 'Through the ACS constraint
'Directory.TypesOfChildFor', the parent accepts only children
having the types xxx, yyy, zzz'. The 'parent' there would be
'home'. Furthermore, if the creation dialog does not propose any
type for the new object, this means it is not possible to create
this kind of object (an Executable for instance) under this
parent. In all cases, Access Road informs the user about the
reason of the refusal.
The default value '<immutable> directory' has been proposed
for the Access Target type, in the creation dialog. This is a
standardized way to 'freeze' the state of an ACS object. Access
Road uses the pattern '<immutable>' in the type to forbid
most of the updates for this ACS object. This has no thing to
do with the simulation of the object. It simply allows to protect
it from the user errors in Access Road, like a wrong deleting. At
any moment, the user may allow/forbid new changes. To forbid
them, he simply resets the type to '<immutable>', like from
'directory' to '<immutable> directory'. The inverse action
allows the new changes. The base imposes strong constraints on
the type changes, whatever the proposed values in the beamer. For
instance, it is always forbidden to switch from the type
'directory' to 'executable' or '<immutable> executable'.
Thus, the basic type of an ACS object remains unchanged after its
creation.
Again, remember there is a second pattern to forbid the deletion
of an ACS object, and it is based on '<byAcsCreator>'. Such
an ACS object type cannot be changed by the user. He has no
ability to delete the object, as for the 'home' directory.
To delete the 'one'
directory, the 'Delete' button may be used in the list, if 'one'
is selected among the children of 'home'. The second way is:
Select 'one' in the list, then click 'See'. The beamer
displays the directory 'one'. Click the top right button
'Delete it' in the beamer, and confirm the deletion. The
directory 'one' is then deleted in the base, the explorer and the
beamer. The beamer title becomes 'Beamer on a closed element',
until the next selection of a node in the explorer.
Caution: deleting a
Directory in a Resources tree deletes ALL its direct and indirect
children. This is true for numerous software, like an operating
system, but not for all. For Access Road and by default, the
indirect children are deleted whatever the simulated software.
Click the node
'e_jerry' in the explorer, under the node home:: jerry:: d_jerry.
In the beamer, click the tab 'AG'. The
tab title 'AG' means Account/Group. The beamer has the following
state:

The
user may have an Access Road comment
on each property, when
the mouse arrow is near the property name. For instance, the
message 'The main group which contains this resource'
is the tip of the property 'main Group' in the beamer. Most of
the properties of this 'AG' tab are generic, for all of the ACS
managing Accounts and/or Groups. However, the beamer receives
also the description of some specific properties from the
'Ubuntu' ACS add-on, like the property 'other as NX rights'.
|
About
Access Road
Introduction
to Access Road
Two-hours
tutorial for designing access controls
Three-hours
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
|
The purpose of this
tutorial is not to master the simulation of GNU/Linux Ubuntu.
Let's say here that a Linux Resource may have an account and a
main group. They are the two first properties the AG tab
displays. We see the account 'jerry' and the group 'jerry'.
Access Road adds the patterns '<U>' for UserID and '<G>'
for GroupID before the last component of, respectively, any
UserID name and any GroupID name. This is a generic behavior,
true for all the ACS. In the case of 'Ubuntu', an account and a
group may have the same last component in their names, like
'jerry' there.
This AG tab handles
varied buttons we have to study. The properties are associated to
new buttons, as followings:
'See'
has already been used in this tutorial, to display an object in
the beamer,
'Select'
allows, for a single value or a list, to update a value in the
base, through its selection in the explorer or in a displayed
list; it is used instead of 'New' for selecting and not creating
an object, as for instance the account to select for the
executable 'e_jerry',
'Clear'
sets a single value to null,
'Remove'
replaces, into a beamer list, the 'Delete' button for removing
in the list without deleting in the base; the link between the
two objects is deleted, but the removed object remains visible
in the explorer,
'Prev.'
means 'previous' in a list, to copy the values of the upper list
in the beamer tab into the current list; for instance, click it
for 'main Group rights' would set the rights to 'ctrl' only, by
copying from the previous property 'Account rights' into the
same tab.
With the button 'Select'
of the Account property, it is possible to select an UserID in
the explorer. Click the Account 'Select' button: the
following little dialog appears. It gives the type of the
selection to do: 'UserID'. To NOT change the 'e_jerry' account,
click the button 'Cancel' of this dialog.

The behavior of Access
Road may vary. With the button 'Select' of the 'Account rights'
property, the explorer is not implied. A list of rights appears
for the selection. Click the Account rights 'Select' button.
The following window appears:

Access Road displays the
rights without redundancy. There are two cases. If you select the
right '|mdown|', it is added to the 'e_jerry' list. If you select
another right, it would not appear into the beamer list. This is
because the current ACS right 'ctrl' includes the three rights
'w', 'x' and 'r', from the 'Ubuntu' ACS point of view. If you
have added '|mdown|', select the right '|mdown|' in the
Account right list, and click the 'Remove' button to return
to the initial state where 'ctrl' is the single account right.
Otherwise, close the 'Selection' window for the rights. On
the other hand, the property 'main Group rights' displays the two
rights 'r' and 'x' because they are semantically independent.
An ACS may deliver
complementary data about its properties. Click the node
'tubun' in the explorer, and click the tab 'See Why' in the
beamer. This map uses as
keys, in the list at left, the property names the beamer displays
for this ACS. Click the key 'All the rights'. The
value at right is a short text describing the logic of the
'Ubuntu' rights.
Creating an ACS
object
The creation of a new
Resource may be done from its parent, as we have seen there for
'one', but also from its ACS, from the tab 'Access Targets' and
the property 'Own Resources'. Generally speaking, if the ACS
manages all the possible features (this is false for the Ubuntu
ACS), the beamer ACS tabs allow to perform the following
operations:
into the tab 'Right Users',
creating an EligibleParty (UserID, GroupID, Actor,...)
from the property 'Own Eligible Parties', and creating a
Right-User VirtualFolder from the property 'Right-User
VFolders',
into
the tab 'Access Targets', creating
a Resource (Resource,
Directory, Actor,...) from the property 'Own Resources', and
creating a VirtualFolder
of Resources from the
property 'VFolders of Resources',
into
the tab 'Rights 2', creating
a typed privilege from
the property 'Typed Privileges', and creating
a linked privilege from
the property 'Linked Privileges',
all
the other ACS properties in the beamer offer to read a property,
not to edit it.
An AclEntry is
always created from its Resource, at the tab 'ACL'. The Bridge
is created from the Actor which is the Bridge source. The Hard
Alias is automatically created when its hard reference is
created. The Soft Alias is created by program, never
through an user command. The ACS rights are defined only
at the creation of the ACS. Note: this description does not take
account of the adaptive presentation by the beamer, which may
remove the displaying of some properties.
All the other relations
between two ACS objects are made through a selection of an object
into the explorer, without creation of a new object in the Access
Road base. For instance, the Account/Group rights are managed
mainly by the Resources, as internal properties.
To
summarize, the behavior of the beamer at each selection depends
on the property and the ACS. Access Road indicates what type in
the explorer is expected, like UserID there, or it displays the
list of the new values the property may have, like the Account
rights here. The user choice in the explorer is checked by the
base, and the new values list comes from the ACS policy. Finally,
you simply have to know that Access Road works for you to
authorize the allowed values, at any property change.
|

About
Access Road
Introduction
to Access Road
Two-hours
tutorial for designing access controls
Three-hours
tutorial for verifying access controls
Why
Access Road is unique
Glossary

|
The sketcher
Let's
take now the easiest part of this tutorial: the sketcher.
In the main menu, select the command Window → Sketcher.
Select in the explorer the Executable 'e_jerry'.
The sketcher window
appears at the bottom right of the Access Road window. You should
extend the window for having the following image:

The sketcher always
shows the current selection of the explorer (and the beamer) like
'e_jerry' there. At each selection, Access Road chooses the
objects to put around the selected object. The user cannot modify
the view in the sketcher. The drawings of the ACS objects depend
on their general types. These drawing patterns are common to all
the ACS in Access Road, and to all the kinds of views.
The sketcher contains
the following items:
the
central node is the current selection: 'e_jerry',
at
the top line, the main direct right users which have an access
on 'e_jerry'; there are its account 'jerry' in a smaller
drawing, and the groups 'jerry', 'users' and 'AllUserAccounts';
as you may see, executables (as 'e_jerry'), accounts (as
'jerry') and groups have each a specific standard drawing,
common to all the views,
at
the bottom line, the main direct objects on which 'e_jerry' has
some rights: 1 account and 3 groups are displayed, and there are
sometimes redundancies with the top line,
most
of the effective rights are shown near to the arrows or
lines between the nodes, and they are explained in the next
tutorial,
the
account 'jerry' has the generic right 'fulctr' (that is,
'full_control') on 'e_jerry', and '[own]' means simply this
account owns this resource; of course, this data is the image of
what the beamer displays in the relevant property fields,
the
group 'users' has the 2 rights 'x' (that is, 'execute') and 'vw'
(that is, 'view') you may consult under the explorer node 'types
of ACS right',
click
the ACS right 'x' in the explorer, and read the property
'Generic Right' in the beamer; the
sketcher becomes an empty Grey rectangle, because it does not
manages the rights nor the ACS, but only the ACS objects,
in
the beamer, click on the back icon to return to the Actor
'e_jerry'; this action
resets the sketcher,
the
executable 'e_jerry' has the link 'init contxt' (that is,
'initial context') on each of the 4 bottom objects; in the
glossary, this term is presented as 'In a view, when there is an
access path to an Actor starting under a given UserID or GroupID
context, this actor runs under this UserID or GroupID, as
component of the proper AG context of the Actor. A relation 'Run
under' is created in the view from the Actor to the relevant
UserID or GroupID. This relation is displayed in the view
diagram as a line with the comment 'init contxt' (for 'initial
context')'.
Access Road handles in
the views several links, like 'init contxt' there, which are not
simply the rights between two objects. The glossary
defines all the link types Access Road uses in any view. They
will be presented in the next tutorials. In a view, the only
active objects – on which a click is operating – are the
nodes, not the links or the rights.
Click the node of the
group 'users', to select it in the explorer. 'users' becomes
the central node into the sketcher. In this case, the sketcher
shows the members of 'users' since it is a group, and it shows
the executable 'e_jerry' as right user. 'e_jerry' is the single
target.
In the sketcher title,
'no updating' means the sketcher view does not change if some
rights or some relations are changing in the Access Road base.
The sketcher is the simplest view in Access Road, while the other
views are updated on-the-fly. If the object to display has too
numerous links, like an ACS or a right, or if there is no link at
all, like a view, the sketcher displays a Grey rectangle. The
most complex rights are not processed in the sketcher, even if
they are direct. For instance, with an ' Ubuntu' file, the 'AG
Other' rights and the AG inherited rights are not displayed.
Click on the explorer
to activate it. Use the key '↑' of the keyboard to select in
the group 'tty', then 'tom' and 'sys'. See the result in the
sketcher.
In conclusion, the
sketcher is designed to simply jump from one object to another.
It shows the simplest direct links and rights. Try it on any
'tubun' object, and enjoy its simplicity!
With
the explorer, the IS structure, the beamer and the
sketcher, Access Road offers an universal user interface. It
becomes more easy to understand varied software simulations.
Let's
now apply our new skills for learning how Linux enforces the
account rights of a new Resource, from the account properties.
|

About
Access Road
Introduction
to Access Road
Two-hours
tutorial for designing access controls
Three-hours
tutorial for verifying access controls
Why
Access Road is unique
Glossary

|
Understanding Linux umask
It
is recommended to save
the Access Road base now,
for reusing easily this state in the next tutorial:
In
the main menu, select the command File → Save All (or, Ctrl+s)
Select in the
explorer the Executable 'e_jerry'. Click the 'Select' button for
the property 'Account', in the tab 'AG'. A selection dialog
box appears at the top of the main window. Select as new
Account, in the explorer, the UserID 'games' under the node
'UserIDs (right user)'.
Caution: there is also a GroupID named 'games'.
The 'e_jerry' account is
updated normally, but also all the other properties in the 'AG'
tab. If it is still open, the sketcher does not change. The
sketcher is then wrong, until the next normal selection in
the explorer! To close the sketcher, simply click the top
right cross of its window.
The property changes are
due to a requirement in the ACS 'tubun', to simulate GNU/Linux
Ubuntu. Editing a Resource UserID produces the following changes:
the
selection of the new-UserID default group, for being the new
main group of the resource: the GroupID 'games' there,
the
umask values of the new UserID are applies to the 3 AG rights of
the resource.
Note: This is an example of an ACS behavior it is not possible to
specify through the default ACS properties. It is too complex.
This is the responsibility of a specific code in the ACS add-on.
To understand this ACS behavior, the user should read the ACS
add-on 'Ubuntu' documentation... or it may use Access Road to see
it in action.
Click
the 'See' button of the Account property. The
beamer shows the 'AG' tab for 'games'. The property 'UMask
for denying' has the default value 'rwx --- ---'. We will see how
this property defines the 3 current 'AG' rights of 'e_jerry'.
Select the UserID
'jerry' in the explorer. Its
umask is '--- -w- rwx'. At this step, if you are not familiar
with the Linux umask concept, you should tell: how does it works?
Let's see the power of a
simulator helping to learn Linux access controls. This is
an example of the services Access Road provides for any simulated
software.

Let's
set the mouse arrow on the property 'UMask for denying', to read
this tip: 'The umask format is 3 independent sets '___ ___ ___',
where the ranges in each set are from '---' to 'rwx' for the
Account rights, the Group rights, and Other rights'. To see it in
practice, it is interesting to change the umask of, say, the
UserID 'jerry', then to reset the Executable 'e_jerry' account to
this UserID.
The
initial 'other as NX rights' of 'e_jerry', under the 'jerry'
account, was 'x' (see the image in 'Editing a list'), but this
was not due to the 'jerry' umask. We will use it now for
'e_jerry'.
Click
the executable 'e_jerry' in the explorer, or click the beamer
back button until 'e_jerry' is displayed. In the beamer, click
the 'Select' button for the property 'Account' in the tab 'AG'.
In the explorer, select the UserID 'jerry'.
The property ''Other' as NX rights', under this new 'jerry'
account, becomes null.
Click the account 'jerry'. In
the tab 'AG' and for the property 'UMask for denying' , instead
of '--- -w- rwx', replace the last value 'x' by '-'; enter
'return' to update the base.
Click
on the beamer back button to be once again on the executable
'e_jerry' and the tab 'AG'. To reset the 'e_jerry'
account to 'jerry' one more time, repeat the previous procedure.
This
resetting of 'jerry' enforces the reading of the new 'jerry'
umask value. The result is a right 'x' for the property
''Other' as NX rights' of 'e_jerry'.
The
removing of 'x', in the third section of the 'jerry' umask, was
about the 'other' rights. It has produced a new 'x' 'other' right
for 'e_jerry'. This is why the umask name in Access Road
is 'UMask for denying'. 'x' is removing from the resulting
new rights of a resource, if it is in the account umask.
Otherwise, like now, 'x' is put in the new rights each time the
UserID is changed.
Note
1: in Access Road, the base is always consistent. Any property
change is propagated to all the relevant objects. The user has
never to command explicitly the updating of the linked
properties, like here the relation between the Resource UserID
and the Resource ''Other' NX rights'. While the previous
procedure resets the same account 'jerry' to read its new umask,
this is not a design error in Access Road. This is due to the
specification of the umask. This property is ridden by GNU/Linux
Ubuntu only when the account is changed or the resource is
created. Access Road simply simulates this behavior.
Note
2: the beamer displays a string property into a text field. This
is the single case where a property is edited without using
buttons. The umask is an example of such string property. The
beamer updates this property into the Access Road base only when
the user enters a 'return'. In an independent process, all the
property changes in the base are listened and displayed by the
beamer. For a string property, an entered empty string, or a new
string containing only white spaces, is converted by the beamer
as a null value before updating the base.
Note
3: The umask of the UserID 'jerry' does not explain the initial
values of the 'e_jerry' AG rights, at the creation of the ACS,
because the ACS add-on provides an additional setting.
We
have seen the umask value is composed of 3 sections for driving
the 3 Account, Group and Other rights. To continue the test of
umask, it is possible to change the 'r' and 'w' values in the
umask for Account, for instance, and to repeat the previous
procedure. Keep in mind that, in the ACS 'Ubuntu', 'ctrl' is the
sum of the rights 'r', 'w' and 'x' on a Resource.
One
should tell each access control concept is not very difficult to
understand. But unfortunately, these concepts are precise and
very varied from one software to another one. The next tutorial
will give a second example with MySQL Server®.
Access Road is truly unique to learn the access control
concepts in action, and to remind them quickly.
Exit
Access Road
We
hope you enjoy this first Access Road tutorial. The next one is
for designing access controls.
To exit Access Road:
In
the main menu, select the command File → Exit
A
dialog box requests if you choose to save all the open ACS, views
and GUI configuration.
Click
the 'No' button.
Then,
the changes about the umask are not saved.
The
main window is closing. At the next opening, the locations of the
open internal windows at the last saving will be restored, with
the same open ACS.
|

About
Access Road
Introduction
to Access Road
Two-hours
tutorial for designing access controls
Three-hours
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|