Access
Road 0.7.3 Verifying access controls
|
|
Creating
RBAC |
ACS
properties |
Discovering
RBAC
Adding
an user comment |
Creating
NoMore-NoLess view |
Negative
rights
User identity and context switch |
IP addresses and 'black'/'white' senders lists
Exchange point |
Typed and linked privileges |
Export
and import
Comparing
two access control states
This
third tutorial explains several independent matters, like how to
verify the access control set-ups of a simulated software, and,
from the release 0.7.3, how to handle the user identity and the
IP addresses. It takes the example of a Role-Based-Access-Control
application. The RBAC model of access control is well-known in
security. It is used to simulate a theoretical application into
Access Road.
This third tutorial is recommended to all the users. However, it
is not mandatory to read it to perform Access Road, and it is
also possible to skip some sections. The second tutorial is a
requisite, but it is not necessary to know the RBAC model. This
third tutorial introduces the following features:
creating
a RBAC application as a new ACS,
introducing
the complex properties of an ACS (optional),
how
to discover the RBAC application, and to analyse the access
control strategy of a software,
creating
a NoMore-NoLess view to check the compliance of rights with some
criteria,
comparing
the full views and the NoMore-NoLess views,
adding
comments to a full view,
introducing
the negative rights, through the example of AclEntries
(optional),
managing
the user identity in the sessions implying several software, and
handling the context switches (optional),
working
with the IP addresses, the exchange points and the access
controls on sender lists (optional),
introducing
the linked and typed privileges (optional),
using
the export and import functions (optional),
comparing two states of
access control for the same instance of a modeled software.
The best way is to use
twice each chapter of this tutorial: first as a simple reading,
and then to operate on Access Road. The total duration is
estimated at 3 hours. When a chapter is optional, it is
independent of the other ones and this is recalled at its start.
How to exit Access Road
and save the current configuration is shown at the end of this
first tutorial.
Creating a RBAC application ACS
Run the Access Road
program from the installation instructions. Close the central
information box. Close all the open ACS, by selecting each ACS
node then through the command File → Close. Select 'Yes, with
saving' to the message requests.
Some other ACS may be closed because they are children of the
selected one. Some messages may appear to indicate that the open
views are closing, since they are associated to a closing ACS.
Confirm all these messages. Close the Sketcher if it is
opened (click the window cross).
We
follow the procedure to create an ACS, from the first tutorial.
The new application runs on a specific Linux server we create
first. To create the out-of-the-box simulation of a Linux Ubuntu,
select in the main menu the command File → New →
'New Access Control system'. A
window appears. Enter the name 'IO'
for the ACS IS, the name 'hu' for the new
ACS, select the choice 'Linux Ubuntu 8.04', and click the 'OK'
button.
A
dialog selection appears about the parent. Click the
node 'IO:: ' then 'OK', to
create the new ACS (indirectly) under the IS root. A second
question appears to create a new component. Click 'Yes'
then 'OK'. A dialog named
'NEW COMPONENT under IO::' appears to create a new child of the
root. Enter the name 'three' and click the type
'physical' to create a physical component for the new Ubuntu,
then click 'OK'.
A last dialog proposes to create another component. Click 'No'
then 'OK'. The Linux Ubuntu ACS 'hu' is created, saved,
opened and selected in the explorer.
To create the out-of-the-box simulation of a RBAC application as
a GNU/Linux Ubuntu application, select in the main menu the
command File → New → 'New Access Control system'. A
window appears. Enter the name 'IO' for
the ACS IS, the name 'rbc' for the new ACS,
select the choice 'RBAC application', and click the 'OK' button.
A dialog selection
appears to select the direct parent. Click the node 'IO::
three:: hu' then 'OK', to set the new RBAC application under
the node of the Linux Ubuntu 'hu'. A second question appears to
create a new component. Click 'No' then 'OK'. A
dialog 'Select the parent ACS' appears. Select the
single choice (the ACS 'hu')
then click 'OK'.
Confirm the 3
messages about the creation of the ACS components. The RBAC
application ACS 'rbc' is created, saved, opened and selected in
the explorer.
You should have the
opening of at least two internal windows: the explorer at the top
left, and the beamer at the top right. If the beamer is closed,
select in the main menu the command Window → Beamer.
The explorer shows for the RBAC application 'rbc' the common
nodes we know for an ACS. In the beamer, the ACS tab 'Structure'
shows the 24 booleans defining the main structural properties of
an ACS. This is a simple ACS structure, where the main
properties are 'internal/external AclEntries' and 'nested
accounts groups'. This latter boolean is new, since not Ubuntu
ACS nor MySQL Server ACS manage it.
In the explorer, under the 'GroupIDs (right user)' node, there
are two subACS called 'functional_tree' and 'physical_tree', as
examples of nested account groups. The functional tree of
groups is the ground of the role-based access controls. Under
the node '<functional_tree>', there is a tree of more than
20 functional groups.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Two-hours
tutorial for designing access controls
Why
Access Road is unique
Glossary
|
Introducing t he
complex ACS properties
For
the advanced users, this optional section explains how to
configure some ACS properties to get a given behavior. This
section does not help to understand the other sections.
We
have seen in this
first tutorial that Access Road may forbid the creation of a
kind of ACS object under a given directory 'home'. There is no
Linux rule nor Ubuntu rule there, but an application of the best
practices in the Linux Ubuntu administration. This is an example
of how Access Road goes over the basic simulation of a software.
The ACS property which is responsible of such a behavior for
Linux Ubuntu is the generic property 'Container / Resource / ACL
/ Privilege type POLICIES'. But first, let's see the properties
of 'rbc'.
Click the explorer
on the node 'rbc', then in the beamer click the tab 'Types'.
Do not hesitate to enlarge the beamer window if necessary. In a
beamer map, the keys list is at left. The selection of a key
produces the display of the associated values at right. In the
left list of the property 'A. All the ACS object TYPES...',
select the key 'Resource.ResourceType'
(at the end of the list). The following map should appear:

This first property 'All
the ACS object TYPES, and all the 'CreationByBeamer' type POLICY'
is a complex map configuring several features of an ACS. Let's
just say this key 'Resource.ResourceType' defines all the
possible types a Resource may have in an ACS, whatever the kind
of Resource: simple Resource, Directory, Actor,... The number of
workable types is there quite low. All the RBAC application
Resources are modeled as Actor transactions put in some sets. The
main RBAC access controls are simply about what right user may
access to each Actor transaction.
In the left list of
the same property 'A. All the ACS object TYPES...', select the
key 'EligibleParty.EPType'.
The key
'EligibleParty.EPType' defines all the possible types an
EligibleParty may have into this ACS. An EligibleParty is the
main kind of right user, as an UserID, a GroupID or an Actor. The
list at right shows a greater number of values that are ended
with 'role' or 'group'. Once again, we find the functional group
names.
The ACS properties cannot be changed after the creation of the
ACS. The ACS designer allows or not the Access Road user to
change the type of an ACS object freely after its creation. This
is the responsability of the
second property 'Container / Resource / ACL / Privilege type
POLICIES', in the same beamer tab.
For
instance, in an Ubuntu ACS, the key
'Directory.TypeOfChildFor.directory'
defines the allowed types for the children of a standard
directory. The values list contains 'directory', 'file' and
'executable'. There, for the ACS 'rbc', there is no key
'Directory.TypeOfChildFor.directory' since 'directory' is not a
Resource type. The sixth key
'Directory.TypeOfChildFor.transaction set' has only one value:
'transaction'. A generic rule for all the ACS is that the value
'xxx' authorizes also the value '<immutable> xxx'. The
child of a 'transaction set' may have the type 'transaction' or
'<immutable> transaction'.
This
second property 'Container / Resource / ACL / Privilege type
POLICIES' has many other functions. For instance, Access
Road forbids in the ACS 'rbc' the adding of an UserID as member
of some GroupID. This is done through the tenth key of the left
list, named 'GroupID.NoUserIDAsMember', where there 4
values of GroupID types.
Another type policy in
the first property, through the key 'CreationByBeamer.NoType',
has the responsibility to forbid some types at the creation of an
ACS object through the GUI. This key is associated to a complex
list of values, where some of them start with 'UserIDType.' to
forbid a type at the creation of an UserID. For instance, the
value 'UserIDType.administrator role' is set. By the way, most of
the EligibleParty types are forbidden, so that only a 'personal
user account' may be created as UserID by the Access Road user,
for a RBAC application.
Generally speaking,
Access Road manages a network of positive and negative
StringRights. A StringRight models a right and it has a strength.
It may be linked to some upper rights and some lower rights (see
the beamer tab 'Rights' for any StringRight). In some ACS, the
rights are created by pair: one positive right and one negative
right.
For some ACS addons,
there is a name pattern to convert the right of a Directory to a
right on its child. This may lead to create a right the simulated
software does not know, while it is required in Access Road. For
instance, in an Ubuntu ACS, the tab 'Rules' in the beamer
explains:
A pitfall
is that 'r', as an inherited right from the parent, does not mean
'read', as when it is a direct right, but it means 'goto' and
'view'. This is why Access Road defines the right 'rdir' for a
directory. Inherited right or not, 'rdir' has these varied
meanings to replace 'r'.
This tab 'Rules'
explains some complex properties of an ACS.
How a set of rights is
attributed by the ACS is another important function. Click the
tab 'Rights'. The first
property 'A. Standard Rights' defines the simplest rights for
each type of rights, like the Account rights of the Account/Group
rights, and the AclEntry rights. Most of the keys are for varied
Privilege rights. The key 'Resource.AclRights'
defines the standard AclEntry rights of an ACS:

There is no value there because this first property is overridden
by the second one, called 'B. Specialized Rights', which is more
fine-grained. The fifth key
'Source.AclRightsSet.Type.administrator role' defines for
an access source (as 'Source') having the type 'administrator
role', the permissible AclEntry rights (as 'AclRightsSet').

The values are 'administer', 'right update' and 'connect'. The
type 'administrator audit' may use only these 3 ACS rights on any
ACS Resource.
These two images shows what Access Road proposes when an AclEntry
is created for the GroupID 'rights administration' having the
type 'administrator role'.
When an AclEntry is created, the set of permissible rights
cannot be selected until the ACS is known. If the user click
the 'Select_3' button for 'List of Rights' before the selection
of the ACL source (the Right User), the list of proposed rights
is larger. However, the base would reject any new ACL having a
wrong right for the triplet (ACS, source, target). It is
recommended, whatever the object to create, to simply select the
properties in the order of their presentation, like into these
images, to have the better list of values for each property
selection.
Unfortunately, there are still some cases where the permissible
values cannot be known by the GUI at this step, because the
constraints are the result of a complex processing in an ACS
addon. The object creation may be rejected by the base. In all
cases of error, a clear message informs the user about the issue.
To end this chapter, here is a presentation of the ACS roots.
An ACS may be installed as the child of another ACS called its
parent ACS. The parent ACS may contain special roots of this
child ACS, that are the parent ACS components the child ACS
requires to work. For instance, the 'MySQL server' ACS has roots
on its 'Ubuntu' parent ACS, like the program '<files_tree>::
var:: run:: mysqld:: '. A static root is set at the creation of
the child ACS, and removed only when it is deleted. The program
'mysqld' is such an example. A dynamic root is created when the
child ACS is opened, to simulate the running of the software. It
is deleted at the closing of the child ACS. The Linux socket
'<files_tree>:: var:: run:: mysqld:: mysqld.sock:: ' is an
example of dynamic root for the MySQL Server.
A root is automatically created by Access Road, and it is handled
by the user as any object. The user may change the properties as
any object, and the change is saved by Access Road. Each root for
closing is created at the opening of this ACS. If it already
exists, it is not changed to keep its current properties. For a
static root, this is simply the simulation of the single action
of an administrator on the software. For a dynamic root, this may
be viewed as the simulation of a complementary script which is
automatically run after the launching of the software, to change
some root properties. Access Road does not inform the user when
he commands a change on a root. It adds no mark after an user
change on a root, to remind its state is no more its default
state. For a dynamic root, it is recommended that the user adds
manually this information into the comment of the root. For
instance, the user may add the comment 'changed root by user',
and as an option to be more precise, he may complete by ', on
property: XXXXX, from the default value: YYYY'. If two child ACS
use the same root in the same parent ACS, the secondly
opened/created ACS cannot enforce different values on the root
properties. A root generally cannot be deleted. It is common to
be able to change the properties of a root without the right to
delete it. The generic type '<AcsCreator>' is used to
ensure this behavior.
For a parent ACS object, the beamer tab 'As Root' shows the child
ACS using this object as static or dynamic root. Several ACS are
possible. For instance, the key '<ForChildAcsOpeningAndClosing>'
means this is a dynamic root for all the ACS which are the values
of this key. For a parent ACS, the beamer tab 'Context' shows the
child ACS for which this ACS contains static roots. For a child
ACS, the beamer tab 'Roots' shows 3 lists of roots into the
parent ACS, for opening and for integrity, as static roots, and
for closing, as dynamic roots. For a child ACS, the beamer tab
'Root Actions' shows the scripts to create the 3 types of roots
into the parent ACS.
The aim of this tutorial
is not to explain all the ACS properties. The Javadoc
documentation of Access Road is the best entry point to learn how
to create a new ACS. It
shows also how to modify the properties of an ACS copy.
The configuration of an ACS is very flexible. After the ACS
creation, the user is always guided step-by-step to fulfill with
the requirements of the ACS. Here is a last example. To be easier
to use, the beamer does not display some tabs or some properties
when they are not applicable. In the ACS 'rbc', the directory
'finance' has no 'ACL' tab because it is not authorized by the
ACS policy, nor the tabs 'AG' or 'AG inheritance'. All these
features make Access Road is a framework for varied simulators.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Two-hours
tutorial for designing access controls
Why
Access Road is unique
Glossary
|
Discovering the RBAC application
Access Road offers
powerful tools to analyze an unknown ACS. By contrast with the
two first examples of ACS in the previous tutorials, the RBAC
application is build up strictly with the support of the generic
functions of Access Road. The explorer is the first tool to use
for understanding the main components of an ACS. The ACS 'rbc'
has two main sets, the Resources tree and the GroupIDs tree, as
shown in the explorer:
To see in one look the
logic of an ACS, the best way is to create a full view with
well-chosen objects. As we see that 'shareholders' is the first
financial transaction, it may appears a good idea to put it in a
full view with all the finance groups.
In
the main menu, select the command:
File → New → 'New view'. The first dialog
appears. Select 'Full view' then 'OK'. The second dialog
appears to define the full view name. Enter the names 'rbc'
and 'shar' in the two fields, then click 'OK'. The third
dialog appears to select the initial objects of the new view. In
the explorer, click the Resource 'shareholders', then on the
GroupIDs 'finance' and its 3 'finance' members, then click the
GroupID 'extended management' just above 'finance'. If you
make an error, the 'Remove in list(s)' button should be used to
deselect an object. When the view objects list is complete, click
'OK'.
The group 'finance manager' is a
member of both the groups 'extended management' and 'finance'.
This is why it is displayed twice in the explorer. The full view
'shar in the set rbc' appears as a diagram in the right bottom
coin of the main window. With the mouse, increase the
size of the view window. Drag&drop the objects in the view to
get this image, with 'shareholders' at the top, 'finance
manager' below it, and 'extended management' at right of the
diagram (right-click the image to see it better).
This diagram shows that
'finance' has 3 members in this view, and some of them have
complementary rights on 'shareholders'. The sens of a 'member of'
link is given by the position of this text, near the source of
the link. 'finance transient' has an indirect path to
'shareholders' through 'finance'. 'finance' has NOT an indirect
path through 'finance operational' on 'shareholders'. From
'finance' to 'finance operational' and 'finance manager', the
right on 'shareholders' increases, from 'browse' to 'enter' and
'control'.
To see what right is
greater, click the explorer node 'ACS rights' for the RBAC
ACS, and click the right 'browse data'. In the beamer, click the
tab 'ACL' to read the upper rights: 'enter data' is greater than
'browse data'. A click on the 'Upper rights' See button produces
a jump to the right 'enter data' and its tab 'ACL', where it
appears that 'control' is its upper right.
The basic right 'browse
data' is also delivered to the transient accounts in the group
'finance transient', member of 'finance'. The group 'extended
management' has a special role, since it has a medium-level right
'enter' for all the managers, like there the members of the group
'finance manager' .
The actor 'shareholders'
may receive a Group context from most of the groups in this view.
This is the meaning of the 4 'recv contxt' arrows from the node
'shareholders'. 'recv contxt' stands for 'received
context'. It is the inverse relation of 'init contxt', seen in
the previous tutorial.
This view may be
summarized like this: to operate on the transaction
'shareholders', there is a hierarchy of groups. 'finance manager'
has the most powerful right, then there are 'finance operational'
and 'extended management'. At the lower level, 'finance
transient' can only browse data. For this view, the logic is so
simple it is not really useful to read the 'See why' text.
This view demonstrates a
typical pattern in a role-based access control model. The
groups are called functional because they match an organization
of tasks and responsibilities, in the company, to a range of
rights on the varied resources.
Here is a second view
about the rights of the UserID 'Aïcha', as the personal account
of a person which is an account manager. This view has not to be
created by you. It shows us that the logic of rights is the same
for the two transactions 'shareholders' and 'loads'. The same
strategy is applied to two separate sets of groups, for the
accounts domain and the finance domain.

Let's
say Aïcha, in the bottom of the view, needs to consult for three
weeks, some specific data through the 'shareholders' transaction.
It is easy to register her into the group 'finance transient',
visible at its right in the diagram, and to unregister her after
3 weeks. Then, Aîcha may browse the 'shareholders' data through
a very simple administration action. Such
a diagram is very useful to remind the logic of the access
controls.
This is an unique feature of Access Road.
Note:
this view cannot be get by your Access Road program. It has
modeled 'shareholders' and 'loads' as simple Resources, and not
Actors, to have a simpler presentation without any 'recv contxt'
link.
Using a strong structure of roles
modeled as groups, the
design of access control in the RBAC application fulfills with
some balanced requirements. We
will not study them in details. The limited examples presented
above are sufficient to catch the essence of the RBAC model. The
requirements are summarized hereafter:
Simple
creation of a new application user by its adding in one physical
role and one functional role,
Simple
choice of the correct functional role for the user, since the
functional roles are the image of the organizational structure
or the company,
Simple creation of
complementary denying from the physical locations of the user.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Two-hours
tutorial for designing access controls
Why
Access Road is unique
Glossary
|
Adding an user comment to a full view

A full view supports
short user-defined comments
since Access Road 0.7.3. Select the opened full view,
and into the beamer, the 'New' button of the property 'Elements &
comments'. A dialog window
appears. Select 'Comment to write' then 'OK'. A
dialog 'Enter a new command line, at number 1,...' appears.
To
limit the size of the comment, the dialog forbids a text larger
than 12 characters. Enter the text 'the most' then
'return' or click 'OK'. A
second dialog appears. You may close it to stop the text edition,
or you may enter a second short line of text. If the text is too
long, there is the error message 'This line of comment is too
long. 12 characters is the maximum'. In such a case, click
'OK' to close the error window. A
new dialog window will be displayed to enter a new text. The
procedure is repeated for entering a third line. You may choose
to enter 'powerful'
as second line, and 'group'
as third line.
At
the end, a question window appears: 'Do you confirm this view
comment?' The window recalls the 3 lines of entered text: 'the
most, powerful, group'. Click 'OK'.
Otherwise, the procedure would restart to enter from 1 to 3 new
lines of text. Closing the dialog window of the first line of
text, or letting an empty field when the OK button is clicked
would stop the creation of the user comment.
The
new comment is displayed in the beamer and into the view diagram.
The upper case is not workable there. The comment is numbered at
0. The next comment would have the number 1, and so on. Since
this first comment is about the 'finance manager' group,
drag&drop the image of the comment at the right of
this group, in the diagram.
The drag&drop action handles the view element icons and the
comments the same way.
The user comments are saved with their current position in the
diagram. There are not displayed by the 'See why' text. An user
comment is deleted exactly like a view element, that is, through
the property 'Elements & comments' into the beamer.
Save your current
work through the command File → Save All (Ctrl+s).
|
|
Creating a NoMore-NoLess view
By the way of a clear
diagram, the full view 'rbc:: share' shows the general logic of
the rights. When the IT system is complex, implying varied
personal and skills, a good practice is to write a security
policy for the access controls. A policy contains some rules like
this one: Only a finance manager has a total control on the
operations of the transaction 'shareholders'.
The aim of a
NoMore-NoLess view is to control the compliance with some policy
rules about one access target. It
allows to set a maximum right, the NoMore right, and/or
a minimum right, the NoLess right. A NoMore-NoLess
view contains exactly one access target. This kind of view checks
if, among the set of right users the view contains, there is one
right user which has a right greater than the NoMore right. The
same principle, in the inverse sens, is applied for the NoLess
right as a criterion of compliance.
To control the previous
policy about the transaction 'shareholders', a NoMore-NoLess view
may contain 'shareholders' as single target, and several right
users to check if a 'total control' is get on this transaction.
In
the main menu, select the command:
File → New → 'New view'. The first dialog
appears. Select 'NoMore-NoLess view' then 'OK'. The second
dialog appears to define the view name. Enter the names 'rbc'
and 'shar2' in the two fields, then click 'OK'. The third
dialog appears to select the initial right users (not the single
access target) of the new view. In the explorer, click all the
Account and Finance GroupIDs of the second full view the last
section displays, except 'finance manager'. If you make an
error, the 'Remove in list(s)' button should be used to deselect
an object. When the view objects list is complete, click 'OK'.
The NoMore-NoLess view 'shar2 in the set <NMNL> rbc'
appears as a diagram in the right bottom coin of the main window.
But this is not a workable view, until there is an access target
and at least one right as criterion. To check the policy “Only
a finance manager has a total control on the operations of the
transaction 'shareholders'”, we choose to select the right just
under 'control', that is 'enter data'.
In
the beamer where the view is visible, click the
'Select' button of the property 'Access Target'. Select the
resource 'shareholders'. Click the 'Select' button of the
property No-More-Than right'. Select the right 'enter data'. Use
the mouse to enlarge the new diagram.
The NoMore-NoLess view should appears with its selected 8
GroupIDs, and a 'enter data' right in red.
To
provide an efficient checking on the policy compliance, a
NoMore-NoLess view considers not only the rights of its
user-selected right users, but also all the right users that are
associated to. This means, for an UserID or a GroupID
right user, all the Actors which run under it. This
includes also, for a GroupID, all its direct and indirect
members.
This
extended set of right users may be large for a view. It defines
the property 'Checking Perimeter'. In the beamer, click
the tab 'Context'. The
property 'Checking Perimeter' displays a list which includes all
the right users of the view, and also, additional objects like
'Aicha' and 'finance manager'.
Click the 'See why' button of the view. It
is much simpler than a full view text. The main result is:
NO COMPLIANCE FROM THE RIGHT USER IO:: three:: hu:: rbc:: <G>::
finance manager:: Link number 1: Global no compliance with the
No-More-Than criterion and it is due to the right 'control'
The 'See why' text of a NoMore-NoLess view describes only the
first reason to tell a NoMore or NoLess criterion is not
fulfilled with. It is not a surprise to read that 'finance
manager' is the first reason there. We may compare the open full
view and the new NoMore-NoLess view. The text 'fulctr' in the
full view diagram is the standard acronym about the metaright
'full_control' (called 'generic right' in the explorer and
the beamer). This metaright is always displayed with this acronym
into all the diagrams, whatever the ACS. On the other hand, the
'See why' text of a full view or a NoMore-NoLess view displays
the ACS right, 'control' there, that has 'full_control' as
metaright. We can see the two kinds of view provide the same
results.
In the beamer showing
the NoMore-NoLess view, click the tab 'General'. There
is an empty property list called 'Excluded R. Users'. This
property allows to declare that some right users are explicitly
excluded from the view checking. Click the 'Select'
button, then select the GroupID 'finance manager'. To
do it, you may click directly the representation of this object
in any view diagram.
The NoMore-NoLess view is updated, turning to Green the 'enter
data' right. To tell where are the excluded right users, the
forms of the GroupID 'extended management' and 'finance' are
drawn in Grey. This recalls there are some exclusions in the
policy control. The 'See why' text tells simply 'In this view,
all the non-null right criteria are fulfilled'.
Whatever the evolution of the properties in the Access Road base,
a NoMore-NoLess view, once created and saved, provides a
continuous control about an access control policy. Close the
related view to stop the control.
A NoMore-NoLess view cannot contain more than 9 user-selected
right users. The number of excluded right users is also limited
to 9. The checking perimeter can contain up to 50 objects. If an
user-selected excluded right user is not into the checking
perimeter, then it is ignored.
On the contrary of a full view, it is not possible to change the
position of a node by drag&drop. However, a NoMore-NoLess
view has plenty of common characteristics with a full view:
it
may handle a diagram and a 'See why' text;
these
two elements are updated at every property change which changes
the view objects or the view rights;
the
diagram icons are active on a click, to select the relevant
object in the explorer;
the
view may be displayed in a dedicated main window, or in the tab
of the general 'NoMore-NoLess Views' window;
an
user comment is possible, but only one, at right of the target,
it
is opened, copied, closed and saved in the same way.
The NoLess criterion
works in the NoMore-NoLess view just like the more criterion, but
with an inversion of the control. The NoLess criterion is drawn
in red when, for at least one right user of the checking
perimeter, all its rights are strictly lesser than the less
criterion. An example is given at the next chapter about the
negative rights.
The NoLess criterion
and the NoMore criterion are strictly independent. The
two criteria may be identical in the same view, to control the
use of one precise right.
A
NoMore-NoLess view is a simple tool to check the rights when
the security policy is near to be fulfilled. It facilitates
both the logical induction of a policy from a given
design, the control at
the end of an on-going design, and
the audit of a stable design.
During the maintenance
of an access control design, a set of NoMore-NoLess views may be
very useful. It is easy to verify if the access control policy is
fulfilled. For analyzing an issue, it is always possible to
create a full view similar to a NoMore-NoLess view. The general
'NoMore-NoLess Views' window may displays 20 views and more
(through the menu command: Window
→ All NoMore-NoLess
Views).
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Two-hours
tutorial for designing access controls
Why
Access Road is unique
Glossary
|
Introducing the negative rights
This
chapter is optional and independent of the other ones. At the
moment, the tutorials have handled only positive rights. This
optional section explores the use of negative AclEntries in a
RBAC application. There is a property 'Denying Rights' in the tab
'Rights' of an ACS. We create two new views for the transaction
'loads'.
Follow
the procedure to create a full view named 'rbc:: loads',
containing the transaction 'loads' and the UserID 'John'. Various
access paths are find, and the main right 'control' is get
through the functional group 'accounts manager'.
The
RBAC application uses negative rights to limit the operations on
the base of the physical site from which an user works for the
company. The physical groups are now 'Cilaos' and 'Paris'. The
security officer of this company may think it is prudent to limit
the rights of the personal working at 'Cilaos'.
Select
the transaction 'loads' and, in the beamer, create an denying ACL
with the right 'deny_enter data' for the group 'Cilaos'.
Caution: to create a negative ACL, set the property 'sens' to
'deny'. The view 'rbc::
loads' is updated, and the result is at right. The acronym
'launc' means the right to 'launch' the process 'loads'.
This is indeed the result of a
subtraction of rights: [control - deny_enter_data =
launch]. The lower rights of 'control' are 'deny_enter_data' and
'launch'. In such a case, Access Road subtracts the rights to get
the effective one(s). The first path in the 'See Why' text
produces a negative right.
An
access control policy generally defines the limitations of power
to apply to the users. A policy may also contains the
requirements on the availability of some actions for some users.
For instance, it is important that the key users, like the
administrators, keep on operating on the system. The NoLess
criterion asserts the fulfillment of requirements on
availability.
Follow
the procedure to create a NoMore-NoLess view named 'rbc::
loads2', containing the group 'accounts manager' and the access
target 'loads'. Select the No-Less-Than right 'connect'. Here
is the resulting diagram.
Replace
the No-Less-Than right by 'enter data'. This
criterion is displayed in red, because it is not fulfilled with
for 'John', member of the 'accounts manager' group. This NoLess
criterion assets that the right 'enter_data' is no more available
on the transaction 'loads'.
A requirement on availability is
checked with a NoLess criterion from the point of view of the
modeled software. In this example, we see if the RBAC application
is correctly configured, but this is not a guarantee about the
availability. For instance, if the access controls define a
path through a right-proxy actor as intermediate node, the
current model does not know if this actor provides an effective
access through this path.
Whatever the nodes in a full view,
the overall result is exactly the same, even with some negative
rights. The second tutorial, at the end of the section 'The
updating of an Access Road full view', shows a first-rate link
with its double-length-line arrow in the diagram of the view
'sqyl:: jerry:: '. A first-rate link forbids all the indirect
paths between two nodes.
In
the case of the view 'rbc:: loads:: ', what if the group
'accounts manager', which contains the account 'John', is added
to the view? Add 'accounts manager' to the view. The
result is get there. The 'See why' text displays:
FROM IO:: three:: hu::
rbc:: <U>:: John TO IO:: three:: hu:: rbc:: <rbc
operations>:: accountancy:: loads.
RIGHTS: [deny_enter
data]
PATH NUMBER 1: Link
number 1: Negative ACL: d_enter; -- Global <negative rights
from other paths> <Caution: to subtract to indirect paths>
-- All Rights: deny_enter data
Without 'accounts manager' in the
view, Access Road has performed a subtraction of rights. Now, it
displays independently the negative right 'deny_enter_data' for
'John', and the positive right 'full_control' for 'accounts
manager'. Reading this view, the user has to provide the
subtraction of rights by its own. This is why the 'See why' text
includes '<Caution: to subtract to indirect paths>'. Such a
path is called a to-subtract-to access path. It is not a
first-rate link, since the indirect paths are applicable. Instead
of marking the arrow in the diagram, like for a first-rate link,
a to-subtract-to link is displayed as a normal link. It means
its rights have to be combined to the rights from the indirect
paths, as usual, to deduce the overall rights between the two
nodes.
We have seen the main issues about
the negative rights. The next section describes a last example, when
a context switch produces a false reading of the indirect paths in
a view.
Save
your current work through the command File → Save All (Ctrl+s).
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Two-hours
tutorial for designing access controls
Why
Access Road is unique
Glossary
|
Managing the user identity with the context switches
This chapter is optional and
independent of the other ones. It introduces some improvements of
the release 0.7.3. It may be followed without reading of the
previous chapters on the RBAC application, the ACS properties,
the NoMore-NoLess view and the negative rights.
Access Road allows to manage
the user identity through the connections of several software.
This new feature includes the followings:
how a software uses 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,
how the behavior of the call and
data paths is simulated from a first modeled software ensuring
the initial user session, through a second modeled software and
its own access controls, while it is ended with the components
of a third modeled software having also its own access controls,
how
the active and passive system components of an application are
modeled as roots in an operating system, to handle the data
exchanges between the application and its system.
The concept of principal is an
extension of the concept of user identity. The principal has a
set of accounts and groups which is the ground of its access
rights. Access Road models this set as a so-called Account/Groups
context of an access path.
Going across a frontier between two software often changes the AG
context of an access path. Some ways like (ACS A- ACS B - ACS B)
are possible, so an access path may also keep in memory the AG
context of its first ACS while the last node is processed.
The release 0.7.3 extends the
concept of transfered Account/Groups context. It manages these
transfers between connected software by the way of new concepts:
entry context switch and
exit context switch, communication
end point and data exchange point.
ContextSwitch and ExchangePoint are the new kinds of Actor which
implement these concepts. They ensure the handling
(continuity/deletion/replacement/recovery) of the principal
through the data exchanges in a network. They are also applied
between the processes and the applications of an operating
system.
Using ContextSwitches is introduced in this section. The next one
covers the ExchangePoints. The release 0.7.3 brings also the
managing of the IP addresses,
both in ContextSwitch, ExchangePoint and the IS structure.
IP addresses are presented in the next section.
For exploring the configurations of the session user identity, we
need an Ubuntu server running a RBAC application and a MySQL
server.
Close all the open
views. Following this
procedure, create the MySQL Server ACS 'mys' under
the ACS 'hu'.
In the release 0.7.3, a MySQL server ACS has a new resource by
default. It is called '<entrance_gate>', under
'connection_subacs'. This is an example of entry context switch
(or entry CSW).
To study '<entrance_gate>' in action, let's create a
full view named '3acs:: one'. Populate this view with these 3
'mys' components: '<entrance_gate>', the UserID 'anonymous'
and the table 'Products table'. Enlarge the diagram window and
enlarge the window to get the following image. The 3 nodes
are put at right to let the other places for some future nodes
from the ACS 'rbc' and 'hu'.
1 - The first example shows how an unknown application may
access only to the MySQL account 'anonymous' on the MySQL server.
Look at the properties of the entry context switch
'<entrance_gate>'. In the tab 'General', its default
comment is: 'The MySQL Server gate for all the incoming streams
directly from its GNU/Linux server'. The first step is to explore
the default behavior of '<entrance_gate>', that is, how
the MySQL entry context switch selects the account 'anonymous' by
default. This is the selection when, like in your new view,
'<entrance_gate>' receives no incoming stream. Then, as
Actor, the context switch runs under this MySQL account
'anonymous'. A context switch is displayed in the beamer with a
new tab 'As Switch' we will see later.
Add to the view
'3acs:: one' the UserID 'John' from the ACS 'rbc'.
For the moment, this account has no relation with the MySQL ACS
'mys'. To get the view at right, we will create a first ACL
relation: Select the node '<entrance_gate>' and
its ACL tab; create a new 'rbc' ACL for the right user
'<database_handler>' (in the RBAC ACS, just under the
Resources tree), with the right 'launch' and no condition group.
To create an ACL, see
the second tutorial. This ACL is managed by the RBAC ACS, not
by the MySQL ACS.
The Actor '<database_handler>' is a kind of proxy, into the
RBAC application, for all the RBAC transactions having to access
a database. In the release 0.7.3, it is the common ACL target of
these transactions. The 'See why' text of the view displays 26
indirect paths from 'John' to '<entrance_gate>', all
through '<database_handler>'. There are also 6 hidden
redundant paths, for the same pair of nodes. This is how the RBAC
account 'John' may be logged on the MySQL server 'mys', when it
uses a RBAC transaction.
After the logging of 'John', the switching on a MySQL account is
delivered by the entry CSW '<entrance_gate>'. If the view
would contain only the nodes 'John' and 'anonymous',
'<entrance_gate>' would select 'anonymous' because it does
not know 'John', the calling account. But now, because
'<entrance_gate>' is a view node, the normal paths starting
with '<entrance_gate>' do never consider the potential
callers of '<entrance_gate>' in the same view, like 'John'
there. This is a general property of the full views which would
produce a wrong reading by the user. The access paths implying a
context switch may be confusing, but we will see how Access Road
informs the user each time there is such a risk. Into the diagram
, these access paths are marked by a special symbol at the center
of the arrow. Fortunately, this first example is straightforward.
The user is right to understand that 'John' is logged onto
'anonymous' through the work of '<entrance_gate>'.
Let's remind a full view has to display the same basic data
whatever its current nodes. Removing the node '<entrance_gate>'
from the view, through the beamer list 'Elements & comments',
would simply change the 32 paths 'John'-'<entrance_gate>'
to 32 paths 'John'-'anonymous'. Adding to the view the RBAC Actor
'<database_handler>' would also produce consistent results:
32 paths 'John'-'<database_handler>', one path
'<database_handler>'-'<entrance_gate>', and one path
'<entrance_gate>'-'anonymous'. These examples illustrate
the default behavior of an entry context switch. The selection of
'anonymous' by default is there specific to the MySQL server ACS.
But a context switch may do much more...
2 - The second example shows how an Ubuntu account is logged
into a MySQL account, by the way of a MySQL inner function.
We consider the main feature of
an entry context switch: how the incoming stream is
used to select a local Account/Groups context. The requisite
is to have in the incoming stream a key of the entry switchings
map. In a MySQL server ACS, this feature works only for the
UserIDs of the Ubuntu server under which the MySQL Server runs.
Remove the node 'John' from the view. Add the Ubuntu 'hu'
UserID 'tom' in the view. This image shows the current state
of the view.
In the 'See why' text, from the Ubuntu account 'tom' to
the MySQL 'Products table', the view finds a path through
'<entrance_gate>' and the MySQL account 'tom'.
'<entrance_gate>' switches to the MySQL account 'tom' when
the path comes from the UserID 'tom', because '<entrance_gate>'
has detected the Ubuntu account 'tom' in the Account/Groups
context of the 2 paths tom/.../mysqd.sock/<entrance_gate>.
Let's see the specific properties of a context switch like
'<entrance_gate>'. The beamer tab 'As Switch' displays its
entry switchings map. We see in this image the association
'parent Ubuntu tom'/'MySQL tom'. The user cannot change this map.
It has been set by the AcsAddon MySQL Server. This AcsAddon
updates automatically the map when a new association appears, in
other words, when a parent Ubuntu UserID and a new MySQL UserID
have the same name.
Click
the ACS 'mys' in the explorer; in the tab 'Right Users', click
the 'New' button of the 'Own Eligible Parties' list. In the
selection dialog, select the creation of 'UserID'. In the window
dialog, enter the name 'games', select the type 'account', no
administrative role and 'localhost' as first host. The
MySQL account 'games' is created. Click
the entry CSW '<entrance_gate>' in the explorer, and look
at its entry switchings map in the beamer, at the tab 'As
Switch'. During
the creation of 'games', the MySQL AcsAddon
has
added the
new
key 'IO:: three:: hu:: :: games:: ' to this map, because there is
an account 'games' in the Ubuntu ACS 'hu'.
Note:
Generally speaking, the
entry switchings map may contain several values for an entry key.
The values are GroupIDMembers of the same ACS.
This
is the first example of an access path having, as intermediate
node, a node of the view! The release 0.7.3 allows that because,
in this case, it would not be correct to display a path from the
view node '<entrance_gate>'
to the view node 'Products table'. '<entrance_gate>' is
never an access source by its own for 'Products table', but only
if the incoming stream has some given properties. For
the 2 paths from 'tom' to 'Products
table', the 'See
why' text for the first link tells us, as a Global comment: 'via'
path through: <connection_subacs>:: <entrance_gate>'.
They are the two last components of the name for the first view
node from which the access path is extended.
The access path from 'tom' to 'anonymous' is another special
case. This view should lead to a false perception. The user looks
at some path(s) from 'tom' to '<entrance_gate>', and some
path(s) from '<entrance_gate>' to 'anonymous', while 'tom'
is not logged into 'anonymous'. To inform the user about this
issue, a no-indirect-path path from 'tom' to 'anonymous' is
automatically added by Access Road.
There is no property in the database to directly explain it,
since it depends on the nodes in the view. Such a path
would not be added if '<entrance_gate>' would not been into
the view. This new path has a negative right 'deny_access_to'
('d_acc_t' in the diagram). To explain what indirect path it is
about, the 'See why' text of this path contains the Global
comment: <Caution: no indirect path through>
<connection_subacs>:: <entrance_gate>.
A no-indirect-path path is drawn with a special symbol at the
center of the arrow, where the cross suggests that it is a
denying of access. The symbol is derived from the one used
for the access paths with context switch. This visual association
helps to remind that the no-indirect-path path is deduced from
the paths with context switch. There, the path 'tom'-'Products
table' is deduced from the path 'tom'-'<entrance_gate>' and
the path '<entrance_gate>'-'anonymous'. Access Road is
simple to use and powerful. Whatever the number and the nature of
the nodes in a full view, Access Road detects such a need for a
new no-indirect-path path. For instance, 'mysqld.sock' and
'mysqld' are hidden intermediate nodes into the paths from 'tom'
to '<entrance_gate>'. If these nodes are added to this
current view, Access Road would also detect the need to create a
no-indirect-path path from 'tom' to 'anonymous'.
3 - The third example shows how an application like RBAC
manages its own logging into the MySQL server.
The exit context switch is
the complement of the entry context switch. To explore its role,
we return to the RBAC ACS and its account 'John'. Add the node
'John' to the view. Through the ACL list of '<entrance_gate>',
delete the ACL we have just created, from '<database_handler>'
to '<entrance_gate>'.
The connection from RBAC to
MySQL server is deleted. We will now create an exit context
switch 'mysql_handler' into the RBAC ACS. An exit
context switch completes the AG context when a path goes out of
its ACS.
Click the ACS 'rbc'; in the
tab 'Access Targets', click the 'New' button of the 'Own
Resources' list. In the selection dialog, select the creation of
'ContextSwitch'. In the window dialog, enter the name
'mysql_handler', let a null parent and select the type 'to
database'. The
context switch is created. Select
it in the explorer, and select the tab 'As Switch' in the beamer.
The entry switchings map is empty because the RBAC ACS has not
filled it up. A context switch cannot be both an entry CSW and an
exit CSW. After an user creation, it cannot be an entry CSW if
the ACS is generic, in other words, not from an AcsAddon. Since
the ACS 'rbc' is a generic one, to set 'mysql_handler' as exit
CSW, the user may create a pair (key, value) into the exit
switchings map.
Click the button 'SeleK' for adding a new key to the property
'C. For an EXIT switch, the external AG context for a local key'.
Select the RBAC account 'John'. Click the button 'Select' for
adding a value. Select the MySQL account 'tom'. The
following image shows the result to get in the beamer.

The aim is to control the MySQL logging from the RBAC
application 'rbc', when the account 'John' creates a MySQL
session. We must redirect all the internal paths from
'<database_handler>' to this new proxy 'mysql_handler':
through the ACL tab of this exit CSW 'mysql_handler', create a
new 'rbc' ACL for the right user '<database_handler>' (in
the RBAC ACS, just under the Resources tree), with the right
'launch' and no condition group.
The last step is to restore an ACL path from the RBAC ACS to the
MySQL Server ACS, by the way of this new exit CSW: through the
ACL tab of the entry CSW '<entrance_gate>', create a new
'rbc' ACL for the right user 'mysql_handler' (in the RBAC ACS,
just under the Resources tree), with the right 'launch' and no
condition group (caution: the ACL ACS is 'rbc', not 'mys').
Here is the new state of the view. 3 comments has been put to
inform about the 3 kinds of ACS. Unlike the first use of 'John'
in the view, this RBAC account has now an access to the MySQL
'Products table'. This is the work of the new exit CSW
'mysql_handler', in the RBAC application, to add the Ubuntu
account 'tom' in the AG context of the path. Then, like for the
Ubuntu account 'tom' in this view, the access 'John'-'Products
table' depends on the entry switchings map of '<entrance_gate>'
to select the MySQL account 'tom'.
In this view, there is no path from 'John' to 'tom' because the
switch is done for a precise access path, through 'mysql_handler'
and '<entrance_gate>', not for all the paths from 'John'.
The exit CSW 'mysql_handler' is able to manage the loggings of
any GroupIDMember of its ACS, like 'John', for all the other ACS
to connect to. It may for instance associate to the account
'John', 5 external GroupIDMembers coming from 5 different ACS, or
one external GroupIDMember which is known by all the 5 ACS. On
the other hand, if 2 associated GroupIDMembers are both known by
the target ACS, like the MySQL server there, it is not possible
for the user to constrain the choice by the target ACS.
Note: the result is the same if the exit CSW 'mysql_handler' maps
the account 'John' to the Ubuntu account 'tom', rather than to
the MySQL account 'tom', because the two accounts 'tom' are
associated in the entry switchings map of '<entrance_gate>'.
Generally speaking, this means an exit CSW may add to an exit
path any GroupIDMember from any open ACS. A generic ACS like RBAC
may have an exit CSW, but no entry CSW. On the other hand, the
switchings map of an exit CSW does not handle a default value,
while 'anonymous' is the default result for the entry CSW
'<entrance_gate>'.
This table summarizes the 3 previous examples:

|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Two-hours
tutorial for designing access controls
Why
Access Road is unique
Glossary
|
Managing the IP addresses
and the 'black'/'white' senders lists
This
chapter is optional and independent of the other ones, except the
previous chapter. It introduces the handling of IP addresses as
feature of a communication end point, and the access controls
through the 'black'/'white' sender lists. Context switch and
exchange point are the 2 kinds of communication end point (CEP).
We present, as first example of communication end point, the
entry context switch '<entrance_gate>' from the MySQL
server ACS.
The
communication end point (CEP) may have a
network address and two 'black'/'white' lists of senders.
The network address may
be the full name of an ACSObject, or a node in an IP information
system. In the two cases, this does NOT define a new kind of
access path into the Access Road views. If the network address is
an ACSObject name, the address is simply an aid to the user. If
it is a name starting with 'IPv4' or 'IPv6', the network
address is automatically set as an IP node in the standard
IPV4_ADDRESSES_SPACE or IPV6_ADDRESSES_SPACE information system.
In
the explorer, click the object '<entrance_gate>'. In the
beamer, the tab 'As Switch' displays first the communication end
point properties of this ContextSwitch. To
see the IP nodes into the information systems: click
the menu Window → IS Structure. At
the moment, there is no IP node. A MySQL server has an IP address
to communicate to its MySQL clients. We know '<entrance_gate>'
models the entry point of these exchanges. We add the IP address
'91.198.174.225' to '<entrance_gate>': in the
beamer, click the empty field of the property 'Network address'.
Enter the address 'IPv4:: 91:: 198:: 174:: 225:: ' (you may copy
it from this text), then hit the Enter key to update the base.
The rule to convert the IPv4
address into an Access Road name is to begin with 'IPv4:: ', to
replace '.' by ':: ' and to end with ':: ' (with 2 spaces after
'::'). This is how the IS structure is automatically
displayed after the operation, like after the creation of any new
node.
Of
course, Access Road has changed the address of '<entrance_gate>',
in the base. But it has also created 4 IP nodes from this new
address, in the IS Structure tree. The 3 upper nodes have no
special properties, while the last one is a full representation
of the new IP address. It has in its tab 'General' a property
having the title 'The map keys are the alternates of the ground'.
In the vocabulary of the IS nodes, this node is a 'ground' having
an 'alternate' relation with the object that is a key. The
surprise is the alternate of 'IPv4:: 91:: 198:: 174:: 225:: ' is
not our updated object '<entrance_gate>', but rather 'IO::
three:: hu:: :: var:: run:: mysqld:: mysqld.sock:: '!
'<entrance_gate>'
is the entry point of all the calls to an ACS that models, from
the point of view of the server GNU/Linux Ubuntu, the program
'mysqld' using the IP socket 'mysqld.sock'. The
MySQL server does not deal with the IP communications, since the
Ubuntu operating system provides this service to all its
applications. In the Access Road base, the relevant Ubuntu IP
socket is the bridge source of '<entrance_gate>'. This
explains why Access Road has automatically set this address on
the socket.
Click
the tab 'As Actor' in the beamer, then the button 'See' of the
last property 'Is the bridge target...'. The
bridge source of '<entrance_gate>' is selected by the
beamer: 'mysqd.sock'. Click
the tab 'As Exchange'. The
network address is the same. Into the Access Road modeling, this
IP address may be viewed as both the address of the MySQL server
program, that is the Ubuntu daemon 'mysqld', the address of its
socket and the address of the entry point of the ACS that models
this Ubuntu daemon.
At
the level of 'mysqld.sock', the address network has been set as
immutable by its AcsAddon. But it may be changed by the user on
the ContextSwitch '<entrance_gate>': click the 'previous'
button in the beamer to display '<entrance_gate>', then the
tab 'As Switch', click in the field of the network address to
change it to 'IPv4:: 91:: 198:: 176:: 225:: ', where 176 replaces
174, then hit the Enter key. The address is updated both in the
IS structure and the 'mysqld.sock' object. The previous address
is deleted in the IS structure. This tree shows only the
applicable addresses.
In
this example, 'mysqld.sock' is an Ubuntu exchange point with an
immutable IP address. Generally speaking, the network address of
an exchange point may be changed exactly like the address of
'<entrance_gate>'. The action updates the IS structure by
the same way. Note: the
name of an address may end with a port number as last name
component, after the IP address.
In
the explorer, click the view '3acs:: one'. In the menu, select
File - > Copy view. Enter the name 'two' as second part of the
new view. The view
'3acs:: two' is created with
the components of '3acs:: one'. In the beamer showing this second
view, remove the view element 'John' and add the exchange point
'mysqld.sock' under the ubuntu directory 'mysqld'. Here
is the new view:

A
communication end point, that is a context switch or an exchange
point, may have a 'black' list of forbidden senders for
which any call to this end point is forbidden. It may have also a
'white' list of allowed senders for which any call to this
end point is permitted. The senders may be ACSObjects or IS
nodes. In this latter case, the items of the lists are the
network addresses of the effective senders.
For
the 2 lists, the senders are checked both as first end and
intermediate node before the end point, into each access path of
a view. If a senders list forbids an access path, there is no
way to get this path in a view, because the 2 senders list
overrides all the other stated relations, like the bridge or
the aliasing for instance.
Click
the entry context switch <entrance_gate>, and its tab 'As
Switch'. Copy the network address. Click the button 'New' of the
property ''Closed' white list', and paste the network address in
the dialog box. Click 'OK' to validate the value. Here
is the state of the tab 'As Switch'.
The view '3acs:: one' is updated,
and there is no more path from 'John', because this network
address is the single authorized sender by '<entrance_gate>'.
This is why the white list of senders is called a 'closed' list.
The diagram of the view '3acs:: two' is unchanged. 'mysqld.sock'
is still allowed as sender of '<entrance_gate>' because it
is also its network address.
To
control the use of a context switch, it is possible to set into
the senders white list, the name of this context switch or the
name of its network address. To control the exchanges with a data
exchange point, it is possible to set into the senders white list
the name of this data exchange point, the name of its master
program (this term is explained later), or the name of the
network address of this data exchange point. The hard or soft
alias of an ACS object can be used in a senders white list. On
the other hand, all this is not true for the senders black list
of a context switch or an exchange point, for which an error
message is get in such a case.
Note: setting its own network
address in the white senders list, like for '<entrance_gate>'
there, is an easy way to constraint all the paths through the
entry context switch to use this address.
Add in the beamer the same IP address 'IPv4:: 91:: 198:: 176::
225:: ' to the black list of senders of '<entrance_gate>'.
Into the 2 views, all the
paths to '<entrance_gate>'
are deleted. The black list overrides the white list, so the
presence of 'IPv4:: 91:: 198:: 176:: 225:: ' in the white list is
not considered. If the black list is used alone, it is possible
to be very precise about the paths to forbid.
Remove 'IPv4:: 91::
198:: 176:: 225:: ' in the white list. The
view '3acs:: one' displays again the paths from the account
'John', but not from 'tom'. Its 'See why' text shows there are 32
access paths from 'John' to '<entrance_gate>'.
Several paths have ' IO::
three:: hu:: rbc:: <G>:: extended management:: ' as
intermediate node. It is easy to delete these paths: add
' IO:: three:: hu:: rbc:: <G>:: extended management:: ' in
the black list of '<entrance_gate>'. The
diagram of '3acs:: one' does not change, but its 'See why' text
finds only 14 paths from 'John' to '<entrance_gate>'.
To restore the paths from 'tom': remove 'IPv4:: 91::
198:: 176:: 225:: ' in the white list of senders for
'<entrance_gate>'.
Why
there are now 14 paths rather than 32 is not directly explained
in the 'See why' text of the view '3acs::
one'. Generally speaking, it is impossible to comment the
numerous unworkable access paths of a view. If the user does not
find a given path in the result, he has to remind that a
communication end point applies its 2 senders lists to any access
path.
This last example of 'white' list
demonstrates the behavior of a communication end point, but it is
not useful nor credible to handle the exchanges between the RBAC
application and the MySQL server. To
restore all the paths from 'John': remove ' IO::
three:: hu:: rbc:: <G>:: extended management:: ' in the
white list of senders for '<entrance_gate>'.
Note:
The CEP 'black' and 'white' lists are about the senders only. For
the receivers (e.g. the ACS objects a CEP can or cannot call into
an access path), it is possible to add after the CEP, a new
exchange point as proxy of the CEP outing calls. So, the ('black'
or 'white') list of receivers of the first CEP may be modeled as
the ('black' or 'white') list of senders into the next exchange
point in the path.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Two-hours
tutorial for designing access controls
Why
Access Road is unique
Glossary
|
Managing the exchange points
This
chapter is optional and independent of the other ones, except the
previous chapter. An exchange point is an actor being both a
communication end point (CEP) and a data exchange point (DEP).
A
data exchange point (DEP) models a socket or a pipe for a unique
program named its master program. Taking
the example of Ubuntu, the daemon 'mysqld' is the master program
of its socket 'mysqld.sock'. In this context, sockets are
bi-directional inter-process communication channels; being
available in several flavors, some of them allow communication
through network interfaces, others rely on the system kernel only
as the carrier for local exchanges.
A
DEP has a strong relation to its master program, that is an
Actor. The master program cannot be an ExchangePoint
or a ContextSwitch. It is a 'simple' actor, like the daemon
'mysqld' for 'mysqld.sock'. When
a data exchange point is created, its master program has to be
defined. An Actor may be the master program of several
ExchangePoints.
As a communication end point, an
ExchangePoint rejects the adding of its master program into its
'black' list of senders. The 'white' list of 'mysqld.sock' is now
empty, and the view '3acs:: two' shows 4 paths from 'tom' to this
exchange point. If the 'white' list of senders is not empty, the
master program is automatically added by Access Road: Click
the account 'tom' to copy its name, and paste it into the 'white'
list of senders for the exchange point 'mysqld.sock'.
The
'white' list is updated to contain 'tom' and 'mysqd', the master
program of 'mysqld.sock'. Since the capacity groups are not
there, the paths from 'tom' to 'mysqld.sock', into the view
'3acs:: two', do no more include the 2 paths through these
groups.
Each
connection between two data exchange points are specific to the
ACS, if it is local, or it is handled by a network subACS (for
instance as IP connections). Into an access path, the generic
behavior of an ExchangePoint is to be able to participate as
intermediate node each time it is a right-proxy, and even if
there is no executable right on it. For a common Actor, this is
false when it is not an Alias reference. On the other hand, the
generic behavior of an ExchangePoint is to be an access source
only to a communication end point or to its master program. This
is why a data exchange point has no direct access to a simple
Resource, for instance.
A data exchange point
defines a list of maximal rights for all the sources in the
access paths including this exchange point. The default value of
the maximal rights is 'full_control', which produces no
constraint on the rights of the paths. The values are limited
into the list to the following generic rights: 'full_control',
'read' and 'write'. The list is never empty, and 'read' is the
minimal right. The criterion to compare two rights are the
strengths of their generic rights.
For the property
'Source maximal rights' of the context switch 'mysqld.sock',
select the current value 'full_control', then click its button
'Remove'. The right 'read'
replaces 'full_control' automatically. The
paths from 'tom' to 'mysqld.sock', into the view '3acs:: two', is
now reduced to the generic right 'read'. Click
the button 'Select' and choose in the explorer the generic right
'write'. The
new rights are now 'RIGHTS: [r, w, x, dlrncp]' in the 'See why'
text. The Ubuntu right 'x' appears there because its associated
generic right has a strength which is less than the maximal right
'write'.
How the ACS manages the context
switches and the exchange points is visible in the beamer tab
'Structure 2' of the ACS.
Note:
to get in the property 'Source maximal rights' the right 'write'
alone, the way is to follow the previous procedure, then to
remove the right 'read'. If the current maximal right is
'full_control', the direct adding of 'write' or 'read' would not
work, because 'full_control' contains these two rights.
Save your current work through
the command File → Save All (Ctrl+s).
|
|
Introducing the linked and typed privileges
This chapter is optional and
independent of the other ones. The privileges are not managed by
the current ACS, so we create a dedicated ACS for this chapter.
To create the
out-of-the-box simulation of an ACS for privileges, select in
the main menu the command File → New → 'New Access Control
system'. A window appears. Enter the name 'IO'
for the ACS IS, the name 'priv' for the
new ACS, select the choice 'An ACS for testing VirtualFolders and
Privileges', and click the 'OK' button.
A dialog selection
appears to select the direct parent. Click the node 'IO:: '
then 'OK'. A second question appears to create a new
component. Click 'Yes' then 'OK' to create the node 'five'.

The
ACS 'priv' is created, saved, opened under 'five' and selected in
the explorer. Click its
node in the explorer, and open the sub-nodes to get this image.
This
ACS contains a default configuration including some Resources and
UserIDs, and a set of types and linked privileges.
Under
the explorer node 'Privileges right user >> access target',
there are the two kinds of privileges. The key word 'TYPED' is
for the typed privileges, and the key word 'LINKED' for the
linked privileges.
A
source has rights upon an access target through a typed privilege
if the privilege source type is the type of the given source, and
if the privilege target type is the type of the given target.
For
instance, the first typed privilege 'TYPED || T_one || GO ||
actor_1 >> resource_1', in the explorer, is named 'T_one'
by its ACS, and it delivers the right 'GO' to all the sources
having the type 'actor_1', for all the targets having the type
'resource_1'. A
typed privilege is designed to
produce rights for numerous sources on numerous targets.
The user cannot
change the sources
and the targets of a typed privilege, since it is the
responsibility of the ACS. A typed privilege is created and
deleted from its ACS. The rights cannot be changed after the
creation. Each time the type of an ACS object changes, the typed
privileges of the ACS may take or remove a reference on this ACS
object. A typed privilege does not accept a reference to an
external object, in other words, from another ACS.
Click
the typed privilege 'TYPED || T_one || GO || actor_1 >>
resource_1'. In the beamer, click the tab 'Privileges'. The
main properties are 'Right user type' (or 'Source type') and
'Target type', which are immutable. Under
the 'root_directory', click the node 'res_one'. In
the beamer, its tab 'Privileges' appears, and the first list
'Typed privileges' contains the privilege 'T_one' as first one.
This list has been updated by Access Road because 'res_one' has
the type 'resource_1'.
Create the full view 'priv::
one' with, as elements, the Resource 'res_one' and the UserID
'acc_one'. The
'See why' text of the view displays for the paths from 'acc_one'
to 'res_one', a path given by the typed privilege 'T_two':
-- PATH NUMBER 1: Link number 1:
Typed PRI: GO; -- Global PRI: T_two
-- All Rights: GO
A
linked privilege handles direct and mutable references to its
sources and targets, while the rights cannot be changed
after
the creation of the privilege. This is the inverse behavior of an
AclEntry, which has immutable references and mutable rights. A
linked privilege may have a Resource or a VirtualFolder as
target.
For instance, the linked privilege
'LINKED || L_four || ACCESS', in the explorer, is named 'L_four'
by its ACS, and its delivers the right 'ACCESS' between sources
and targets which are not into its name.
Add
to the full view 'priv:: one' the UserID 'acc_two'. The
'See why' text of the view displays for the paths from 'acc_two'
to 'res_one', a path given by the linked privilege 'L_four'.
The user may update the list of
right users and the list of targets of a linked privilege.
However, the ACS may enforce the types of the right users and
targets of a linked privilege having a given second type. This is
done by the privilege types policy of the ACS. It appears through
the properties 'Internal R-U Types' and 'Internal target types',
in the tab 'Privileges' of the linked privilege. This is why the
selection of the second type is important at the creation of a
typed or linked privilege.
A linked privilege is created and
deleted from its ACS. Click the node of the ACS 'priv' in the
explorer, and the tab 'Rights 2' in the beamer. There are 2
lists for the typed and linked privileges of this ACS, including
the buttons 'New' and 'Delete'.
A linked privilege accepts a
reference to an external right user or an external target, if it
is the ACS policy. Click the tab 'Structure 3' to see how the
privileges are managed by this ACS. The property 'External
One-to-one LPRI' is 'TRUE' to set the external privileges.
In the explorer, the name of a
linked privilege is different if it is external, including the
name of its ACS at the start. The name in the explorer is so
changed when the linked privilege becomes external-oriented. The
privilege types policy of the ACS is also applicable to an
external reference. It is visible at the beamer tab 'Types' of
the ACS.
A linked privilege may inherited
from the Resource or VirtualFolder parent, while a typed
privilege cannot. A linked privilege has no conditional groups,
unlike an AclEntry. This is why the MySQL Server is modeled with
AclEntries rather than linked privileges. On the other hand, an
AclEntry is deleted when its Resource is deleted. A typed or
linked privilege may still exist even if its sources or targets
are all deleted.
Save your current work through
the command File → Save All (Ctrl+s). Close the full view
'priv:: one' .
|
|
The export and import functions
This chapter is optional
and independent of the other ones. The export function allows
mainly to produce PNG images from the Access Road diagrams and
object trees. The import function allows to import in the base an
ACS created by Access Road on an another computer.
Let's see an example of
export of the 'rbc:: <NMNL>:: shar2::' view: into the
'NoMore-NoLess
Views' window. Open
this view.
In
the explorer, click the node of this view. In the menu, select
the command File -> Export image. Select 'Yes' to
confirm the export, and click the 'OK' button.
A message confirms the
export in a PNG format, under the subdirectory 'export' of the
working directory. The procedure is the same with or without the
window 'All NoMore-NoLess Views'. Close the view 'rbc::
<NMNL>:: shar2::'.
The explorer, the IS
structure and the beamer may also be exported as PNG images,
following the same procedure, except that it is necessary to
select the right object to export. For exporting the explorer
rather than a view, it is necessary to not select a view node in
the explorer, while the explorer is the active window. For
exporting the IS structure, its window has to be activated, and a
node into this tree has to be selected. For exporting the current
image of the beamer, the beamer window has to be active.
The operating system
native clipboard may be used to copy any text from the beamer or
a 'See why' text.
The export/import of
an ACS is a powerful feature we do not fully operate there.
This tutorial simply describes the general procedure through a
removing, then an importing of the ACS 'sqyl' into the same
Access Road instance. Each ACS is saved in the working directory
of Access Road in a dedicated file having a name like
'ACS0_IO_three_tubun_sqyl.acr' for the ACS 'sqyl'.
The imported ACS must
have the same ACS version than the current Access Road instance.
An ACS has to belong to an information system (IS), named below
'IS-name'. The imported ACS name has the String form ' IS-name::
aaaa:: bbbb:: cc:: ddddddddddd:: eeee:: ', where xxx is both a
component of the name and a component in the IS structure.
This may forbid the
importation of an ACS if there is a current ACS having the same
file name, or if there is an IS node or area in the same case. It
is not possible to change the name of the imported ACS or the
name of a current ACS.
To import an ACS, it has
to be closed before, into its source Access Road instance. It is
not necessary to remove it from this source instance, and the ACS
has not to be prepared for the export. The imported ACS file is
simply copied from its source Access Road working directory to
the working directory of the targeted Access Road instance.
For our limited example,
we have first to close and to remove the ACS 'sqyl'. If the
ACS 'sqyl' is opened, select in the explorer the node
'sqyl'. In the main menu, use the commands File -> Close. In
the main menu, use the command File -> Remove. Answer 'yes' to
the question 'Remove an ACS?'. Select in the list the ACS 'sqyl'.
Click 'OK' to valid the 2 information messages. Confirm the
removing of the ACS 'sqyl'. The ACS 'sqyl' disappears from
the IS structure.
Note: after the removing
of an ACS, to return to a state exactly like this Access Road
instance had never known this ACS, it is necessary to close and
open the parent ACS if it is opened. The child ACS in the ACS
'tubun' are checked when it is opened, and the removed child ACS
are detected to delete their roots into 'tubun'.
For importing an ACS,
here is the procedure:
Open the ACS 'tubun' which is
the parent of the imported ACS. If
the imported ACS has some roots in another ACS, all these ACS
have to opened before the import. Otherwise, these roots will
not be created, but the import of the ACS would not be stopped.
The commands for the roots will remain, so each opening of the
imported ACS in the future is able to create the required roots.
To import two ACS, one being the child of the second one, the
user has to import and open the parent first.
After the command File ->
import ACS, the user enters the full name of the ACS, as it
will appear in the beamer after the import. The ACS name is
never the name of the ACS file. An error is displayed if the ACS
file, derived from the ACS name, is not find into the working
directory. It is necessary to have one space character at the
beginning of a name, and two space characters at the end of a
name. The user has to enter the text ' IO:: one:: tubun:: sqyl::
'. Copy this text into the dialog window.
If the information system is
unknown, is is added first into the IS structure. The ACS parent
name is compared to the current nodes of the ACS IS. If the
parent name does exist in the IS, the ACS is registered under
this node if there is no child having the same name. If there is
no chain of nodes in the IS to match the ACS parent name, a
chain of nodes derived from the ACS name is created with only
logical nodes.
This is the first ending
message after the importation:

In the imported ACS, all the inner properties are restored,
including its structure, its behavior and its set of ACS objects.
The import function tries also to create the Bridges, the
external AclEntries and external linked Privileges which connect
the imported ACS to the other ACS. It cannot succeed if an ACS is
closed, for instance.
In all cases, the import
function returns a map containing the description of the Bridges,
the external AclEntries and external linked Privileges. This is
the result we should get:

The user may choose to
create some of them, if Access Road has not been able to do the
work. The returned map describes each Bridge, external AclEntry
or external Privilege. For these two last objects, this includes
the names of the rights. It is recommended to copy the
information of this window. It is not possible to get it after
the closing of the window.
In your example, the
information window describes a Bridge which has been created by
the program, from 'mysql.sock' to '<entrance_gate>'. There
is no complementary work for the user. After the operation, the
imported ACS is opened. An automatic saving updates the initial
file of the imported ACS.
Close the ACS 'tubun'.
|
|
Comparing two access control states
From one single
installation of Access Road, an user may run two instances
without any problem if there is no creation or deletion of any
ACS or view. The user change the ACS object properties in the two
instances to compare the results in the open views. There is no
automatic saving in Access Road, so the files in the working
directory will remain unchanged with this procedure. At the end
of the comparison, the user selects the instance to save in the
working directory, and he/she closes the other one without
saving.
To work longer on the
two states of a design, the best way is to handle in parallel two
Access Road directories, after two distinct installations. Each
instance knows only its proper working directory, and the savings
are so independent. It is recommended to keep a manual log of all
the changes in the two bases, if it is necessary to merge some
parts of each design.
Here is a tip about the
savings: an ACS saving has to delete then restore any
external-oriented ACS object, like an external AclEntry or a
Linked Privilege which has a reference on another ACS. After the
ACS restoring, the external object seems to be the same in the
GUI, but it is indeed a copy of the previous one. If the beamer
displays such an external object during the save/restore process,
the beamer displays an empty panel after the operation. The new
copy of the external object appears in the explorer, with the
same properties, and the user may click it to restore it in the
beamer.
A last tip is about the
number of windows, like the explorer window or a view diagram
window, in the Access Road main window. This number is limited to
20. If you try to open too numerous windows, for instance by
selecting several views to open, the GUI will stop to open the
windows after the 20th. A window may then be opened without
title, being empty. In this case, close the abnormal window(s),
and open the two general windows 'All full views' and 'All
NoMore-NoLess views'. This would allow to return to a normal
state.
Exit Access Road
The final state of the IS structure
is the following. A copy of the Access Road base at the
end of this third tutorial may be get from the file
'accessroad073-base-after-tutorials.zip'.
The purpose of the 3
tutorials is to give you the basic knowledge to use Access Road,
and to transmit the 'spirit' of its simulation approach.
There is a first insight on the advanced features. With the examples
of Linux Ubuntu®,
MySQL Server®
and the RBAC application, we hope sincerely these objectives are
achieved.
As a
framework for access control simulators, Access Road is complex
in the details of its work, while its tutorials have to remain
quite simple. Nonetheless, we have tried to avoid a caricature
in the tutorials that distorts or forgets important things.
Remember also that this version 0.7.3 is a work
in progress. There are in the Access Road model several properties
which are still to be fully implemented.
To
exit Access Road and to save the current configuration, let's see
the end of this tutorial.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Two-hours
tutorial for designing access controls
Why
Access Road is unique
Glossary
|