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 the 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


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

®All trademarks are property of their respective holders. Copyright ACCBEE – 25 May 2013