Access
Road 0.7.3 Designing access controls
|
|
Creating
MySQL | Main properties |
Creating ACL |
Generic ACL
| MySQL
ACL Creating full view | 'See
why' text | Full
view updating | MySQL
design Designing
with Access Road
This
second getting-started tutorial is for designing the access
controls of a simulated software. It introduces the MySQL Server®
modeling, as an example of design. If you have only 15 minutes
for a simple reading, you may go to the last section 'Designing
with Access Road'. It proposes 3 strategies based on the Access
Road simulation to design the MySQL access controls.
This is the most
important tutorial of Access Road. It should be ridden by all
the Access Road users. The first tutorial is recommended as a
requisite.
In an ideal world, the
inner complexity of the access control features would be masked
by Access Road. In the real world, this objective is fulfilled in
the view diagrams of Access Road, but not in all the program. The
inner complexity can never be oversimplified when the user wants
to understand the results. Our commitment is to provide an exact
simulation including all the required details. The user may
choose to read only the diagrams, to put it simple, or to go
further.
To build up a thorough
understanding of the issues and their solutions, we think the
best approach is to provide in this tutorial some progressive
explanations combining multiple points of view. This is both the
Access Road way and the spirit that has guided the design of this
present tutorial.
There is no requisite
about the knowledge of MySQL Server®,
as a database management system, to follow this tutorial. We will
discover together the Access Road generic features and a given
simulation. However, this tutorial is a good start for exploring
the basics of MySQL access controls. It explains the following
actions:
creating an Access Control
System (ACS) which simulates MySQL Server 5,
creating a full view to see
the access paths between some modeled objects,
handling the view main
window, the view 'See why' window and the 'Full Views' window,
handling the generic
AclEntries and the MySQL Server AclEntries,
understanding the varied
relations among the objects in a view,
using these features to
discover the MySQL Server access controls, as an example of the
help Access Road brings to the design.
The best way is to read
this second tutorial twice: first as a simple reading, and then
to operate on Access Road. The duration is estimated at two
hours. At any time, you would stop the tutorial before its end.
How to exit Access Road and save the current configuration is
explained at the end of the
first tutorial.
Creating a MySQL Server ACS
Run the Access Road
program from the installation instructions. Close the central
information box. If it is closed, open the ACS 'tubun' the first
tutorial has created, through the command File → Open → Open
Access Control System.
The
explorer and the beamer should remain open. If the beamer is
closed, select in the main menu the command Window →
Beamer. If some other
windows are opened, close them by clicking the top
cross of their windows. Note:
closing a window may imply a saving only if it is a full view or
a NoMore-NoLess view window.
To create the
out-of-the-box simulation of a MySQL 5 Server running on the
'Ubuntu' server, 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
'sqyl' for the new ACS, select the first
choice 'MySQL 5 Server', and click on the 'OK' button.
A dialog selection
appears about the parent. Click the node 'IO:: one:: tubun'
then 'OK', to create the new MySQL Server under the node of
the ACS 'tubun'. A second question appears to create a new
component. Click 'No' then 'OK'.
After a few seconds, the
MySQL Server ACS 'sqyl' is creating in the base, saving in the
working directory of Access Road, then it is opening and
selecting in the explorer.
Click the node 'sqyl'
in the explorer. Following its structure, this new ACS has no
nodes for the external components, but it has an additional node
'Virtual Folder for all (access target)'. A virtual folder is a
folder of Resources, as a Directory. The relation virtual
folder/member is weak, on the contrary of a Directory: deleting
the virtual folder does not delete its members. A virtual folder
is also a proxy node, since it may deliver some access to its
members. The virtual folders are used by the MySQL ACS to model
the MySQL views, which then are not Access Road views. Here is an
example of why it is so important to well know the generic terms
Access Road uses for all the ACS.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Three-hours
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
The 24 main structural properties
of an ACS
In the beamer showing
'sqyl', click the tab 'Structure' to have a first look on
the properties of this ACS. If it is required, enlarge the
beamer window to see all the properties. You should have the
following result:
The
ACS tab 'Structure' shows the booleans defining the main
structural properties of an ACS. To discover an ACS, it is a
good idea to have a look on its 'Structure' tab. There is a
complementary tab 'Structure 2' in all cases, for its general
properties. A 'Structure 3' tab shows the privileges or the
virtual folders when they are managed, like here. Some ACS addon
may provide an additional 'Structure 4' tab. The second tab
'Context' is reserved to the relations with the other ACS into
the information system.
Let's compare the ACS
structures of the 'Ubuntu' ACS 'tubun' and the 'MySQL Server' ACS
'sqyl'. The beamer remembers the last selected tab, and tries to
select it for the next selected object. It is easy to compare two
'Structure' tabs: in the explorer, click the node 'tubun',
then on the node 'sqyl', and repeat.
There are common
properties to 'tubun' and 'sqyl', like the first four booleans,
the Actors, the ContextSwitches, the internal and external
AclEntries, the Bridges and the Soft Aliasing. There are also
great differences: ExchangePoints, 'Account and Group Rights',
'Right-condition ACL' and 'AG rights inheritance' are properties
the 'MySQL Server' ACS does not manage, while the 'Ubuntu' ACS
does it. On the other hand, 'Simple-condition ACL', 'Nested
Account Groups', 'Virtual Folders', 'Virtual Folders Trees', 'ACL
inheritance' and 'Hard Aliasing' are properties which are managed
only by the 'MySQL Server' ACS.
Fortunately, it is not
necessary to understand now all these properties. The preferred
way is a gradual learning. If you are very curious, the beamer
provides a tip for each term. You may put the mouse on a
property title to see the tip. They are also explained in the
Access Road glossary.
To summarize, and even
if all these abstract terms will be explored later, the MySQL
Server ACS manages Resources, Directories, UserIDs, GroupIDs and
ContextSwitches just like the 'Ubuntu' ACS. It does not have
Account/Group rights or Privilege rights, but it has an extended
use of AclEntries, simple-condition AclEntries and ACL
inheritance in the Resources tree. Complex AclEntries are
combined for modeling what MySQL Server calls 'privileges'. They
may be seen as the containers for the MySQL rights. Virtual
folders and hard aliasing are necessary to simulate the so-called
MySQL Server views.
The Access Road
Privilege rights, which are among the 24 boolean ACS properties,
are NOT implied to simulate the MySQL Server privileges. The
reason is, of course, the (lack of) matching between the semantic
of each concept, but this is beyond the scope of this tutorial.
Such inconsistency is impossible to avoid. The rich set of terms
in the generic vocabulary of Access Road is necessary to try to
model a large scope of software. This vocabulary cannot match the
terms of every specific simulated software. To help the
association to the true MySQL terms, each MySQL Server virtual
folder in Access Road has a name which ends with 'view'. For the
MySQL privileges, this is not useful. The AclEntries have no
proper names in Access Road, and by the way, there is no
privilege name in MySQL Server.
The ACS structural
properties drive the choice of the nodes the explorer displays.
Click the explorer nodes of 'sqyl' to get the following image:
As
components, the MySQL Server is modeled mostly as: - a
tree of components in the Resources tree, mainly in one or
several MySQL bases like 'BASE One', - a context switch
as the single entry point for the MySQL server, in the
'connection' subACS, - a tree of MySQL views which
contains some components (the virtual folders), - a set of
users (UserID), - a tree of groups which are
displayed twice, one time located in a subACS tree called
'standard' with strong patterns on names (GroupID), - a set of
AclEntries (ACL) from the users or groups to the
resources.
To simulate the MySQL privileges in the ACS 'MySQL Server', the
simple-condition ACL is mainly a conditional ACL which delivers
rights to the pair (user@host).
MySQL handles this couple to name a MySQL user logged in a given
host. In short (we will elaborate on this later), Access Road
handles this couple as an 'UserID 'with an ACL where the 'host'
is the ACL conditional GoupID.
The
core of the MySQL Server simulation is the following features: -
the management of the ACL inheritance,
through the main components tree of the MySQL Server, -
the pattern-name containers, under the nodes '|pattern-name_bases
sets|' and '<standard_tree>',
which handle sets of resources, accounts or hosts, -
the ACL sorting on a component,
to select the applicable rights of a right user for a given
couple 'user@host'.
An ACL on a Directory is
inherited by all its direct and indirect children, and even by
other resources if it is on a pattern-name bases set. There are
complex rules about the applicable AclEntries for a given couple
'user@host'. In a MySQL Server, there are also some oddities
about the delivering of rights. The first step of this tutorial
is to study the generic AclEntry, then to see how they are
extended to get the MySQL features.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Three-hours
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
Creating a generic AclEntry
Let's see the generic
ACL in the authorization subACS of the ACS 'tubun'.
In the explorer,
click the node 'IO:: one:: tubun:: <authorization_subacs>::
org:: gnome:: clockapplet:: mechanism:: set time zone:: '. In
this authorization subACS, 'set time zone' is an action to
attribute to Linux Ubuntu users through AclEntries. In
the beamer, click the tab 'ACL', and for the first list at the
top of the tab, click the button 'New'. This
dialog window allows to create an AclEntry:

To enter the properties of the ACL:
Click
the button 'Select_1'. A
window 'Selection' appears. Click the node ACS
'tubun', in the explorer. 'tubun'
appears in the field 'ACL manager', and the note '<Set the
ACS first>' in the third property disappears (it recalls the
allowed rights depends on the choice of the ACS).
Click
the button 'Select_2'. A
window 'Selection' appears. In the explorer,
open the 'tubun' node 'UserIDs (right user)', then click the
UserID node 'tom'.
Click
the button 'Select_3'. A
'Selection' dialog shows 5 rights to select in a list. Click
on the third right 'authorize', then click 'OK' into the
Selection window. The
selected right appears in the list, but it is not truly visible.
Do
not click the button 'Select_5'. This
property may remain null, as the comment of its name indicates
it. In fact, the 'Ubuntu' ACS does not manage the
simple-condition ACL, so a non-null value for this property
would be rejected by the beamer.
Click
the button 'OK' into the 'Create a new ACL' window.
We may note that the listed rights for creating this ACL was very
different to the 'Ubuntu' AG rights we have seen in the previous
tutorial. Some proposed values may not be truly authorized. The
user would see an error message which explains clearly the issue.
Note: the message is also displayed in the Java console of
Access Road, but this has not to be considered as a bug.
This
new ACL enables the
right 'authorize' to the UserID 'tom' for the target 'set time
zone'. 'tom' may then
change the time zone into this Linux Ubuntu operating system. The
new AclEntry 'tom >> … set time zone || grant' is created
and shown with this format in the explorer. 'grant' there means
there this is a granting ACL. The opposite value is 'deny'.
In
the beamer, the property 'Right user (RU)' has for value the
UserID 'tom'. An AclEntry may be managed by an ACS different to
the ACS of the right user and/or different to the ACS of the
resource, if the 2 or 3 ACS policies allow it. This has to be
permitted by each implied ACS. We call such objects 'external
AclEntries'.
This is why the beamer tab 'General displays 3 distinct ACS names
for an AclEntry.
The beamer displays the
tab 'ACL' where the effective right 'authorize' for this ACL is
into the property 'List of rights'.
With
one or several condition groups, a generic ACL is called a
'conditional
ACL'.
It is disabled and it delivers no rights if the right user is not
a direct or an indirect member of one of the condition groups.
There are two
kinds of conditional ACL: simple-conditional and
right-conditional ACL (see the Access
Road glossary to go further). These features are used by the
MySQL Server®
ACS and by the RBAC application
ACS.
In the beamer, click
the back button, to go back
to the previous displayed object. The
beamer displays the 'set time zone' action. Its ACL list contains
the new ACL. This ACL name is like into the explorer. The beamer
displays also an 'ACL' tab for the Resources of the 'files_tree'
Resources, but no ACL may be created there. This is a result of
the ACS rights policy. By the same way, the node 'AclEntries:
right user >> access target' appears in the explorer only
for the relevant ACS. The
explorer sorts the AclEntries by their ACL sources. It displays
first the groups then the users.
Note:
this 'Ubuntu' ACS
provides specific features on the Account/Group rights, like the
'umask' feature seen in the next tutorial, while it uses the
generic ACL features of Access Road for its authorization subACS.
In
this section, we have seen an example of how
the generic ACL are handled in Access Road.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Three-hours
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
Handling the generic AclEntry
In the explorer,
click the first AclEntry of the ACS 'sqyl', under the node
'AclEntries...', which starts with '<U>'. The ACL name
is '<U>:: jerry:: >>
MySQL server:: || grant || localhost'. The beamer title becomes
'Beamer: ACL jerry >> MySQL server'.
An
ACL name may have several presentations in the explorer, in the
beamer, in a 'See Why' view text. In
the explorer and the beamer, an
internal ACL name
is
composed of:
'<U>::
jerry:: ' is the ACL right user name (an internal ACL
shows only its two last components, to be concise),
'>>'
to separate the right user to the access target,
'MySQL
server:: ' is the ACL target name, (an internal ACL shows
only its last component, after the ACS name),
'||'
as separator,
the
ACL sens is 'grant' or 'deny',
if
there is an optional group, '||' as separator,
'localhost'
is the last component of the first ACL condition group
name, if it is a conditional ACL.
For an external ACL, the procedure of creation is strictly
the same. The format of the detailed name is as following: ACS:
ACS_name | (full or incomplete) Eligible Party name >>
(full or incomplete) Resource name || grant OR deny || <Source
ACS group> OR <Target ACS group> || first condition
group last component.
An Eligible Party or Resource name is incomplete when the
component belongs to the ACS of the AclEntry. The tag '<Source
ACS group>' indicates the condition group belongs to the
EligibleParty ACS, that is the source ACS.
An
ACL name does not contain the ACL rights, since they may change.
This instance of ACL is conditional, with 'localhost' as first
condition group, while the explorer shows another non-conditional
ACL. In the
beamer on this ACL, click the tab 'ACL'.
In
this 'ACL' tab, the property 'Enabled rights' is true. A
non-conditional ACL simply grants or denies rights without
condition group, and then, 'Enabled rights' is always true. As
a generic concept, a
conditional ACL
enables
its rights only if its
right user
(also
called an ACL source) is
member of all the condition groups
of
the ACL. The property 'Enabled rights' may then be true or false.
This ACL is enabled because 'jerry' is member of the server
'localhost'. To display 'jerry': click
on the beamer tab 'General' and the 'See' button of the first
property 'Right User'.
'jerry' is selected, and its type is 'account'. Click
on the tab 'Members'.
The beamer shows a generic list named 'Is direct member of',
where 'localhost' is the first item.
To
check this ACL, it is possible to use the sketcher : open
the Sketcher with command Window → Sketcher (Ctrl+k).
In
the explorer, select the root Directory 'MySQL server'.
The sketcher finds that 'jerry' has
an 'USAGE' right which comes from this ACL. Unfortunately, the
sketcher handles the simplest cases. It does not processes the
inherited ACL, while they are the central part of the MySQL
rights. For the root having no parent, it delivers a correct
result, but not for the other MySQL Resources. This is the job of
the full views we will see later.
The root 'MySQL server' is now
displayed in the beamer. Click the tab 'ACL'. The first
property, entitled 'Sorted list for users 'account'...', displays
the list of the direct AclEntries of any Resource. 'Direct ACL',
here, is the opposite of 'inherited ACL' that is the role of the
tab 'ACL Inheritance'. The property title is proper to the MySQL
ACS, but it is a generic ACS property. Among other ACL, this list
displays the ACL named:
'<U>:: jerry:: >> MySQL
server:: || grant || localhost'.
The second list, in the same 'ACL'
tab, shows all the right users into the direct ACL of the first
list. In this second list, select the item 'IO:: one:: tubun::
sqyl:: <U>:: jerry::', and click the 'See' button. The
beamer displays the same 'ACL' tab for the account 'jerry'. The
list of Resources contains the ones on which 'jerry' has at least
one ACL. The root 'MySQL server' is a target of one or several
'jerry' ACL. All the links between objects in Access Road are so
managed and displayed into the beamer.
|
|
Introducing the MySQL AclEntry
The account 'jerry' is member of 'localhost', and it is also
logged to the server 'localhost' as its 'First host'. In the
beamer tab 'Members' for the account 'jerry', there is a
MySQL-specific property 'First host', having 'localhost' as
value. For each new UserID, the MySQL ACS enforces the choice of
such a first host. It is defined as the computer from which the
account is logged on the MySQL server.
All this explains why, through a conditional ACL, the MySQL user
'jerry' has the right 'USAGE' on the root 'MySQL server'.
In the MySQL ACS, only one condition group is allowed to an
account. This is not always true into another kind of ACS.
Compared to the MySQL syntax, this conditional ACL indeed
simulates a right statement on 'jerry@localhost'.
The management of access controls by the MySQL server ACS may be
summarized by 6 cases. This tutorial covers the 3 first cases.
The other kinds of MySQL rights are introduced in the MySQL ACS
addon documentation. The simulation of the MySQL Server access
controls in this tutorial can take the following forms:
the
ACL source is a MySQL proxy
having
no proper rights, using the rights of a proxied account as user;
setting
rights of the user to the pair (user@host), through GRANT
statements without
wild-card into the names,
at varied levels (global like this first ACL, database, table,
column and routine levels), and this is simulated by a
conditional ACL for a
MySQL account;
setting
rights of the user to the pair (user@host with wild-card)
through GRANT statements with a wild-card '_'
or '%' only into the host name,
at varied levels (global, database, table, column and routine
levels), and this is simulated by a non-conditional
ACL for an 'accounts-for-hosts' group,
like the first displayed ACL into the explorer: '<G>::
anonymous§@%:: >> MySQL server:: || grant;
We will see now how these two kinds
of ACL are summarized by the beamer, not as a generic ACL - we
have already ridden it at the previous section. They are
summarized to mimic the MySQL syntax for the right statements.
To return to the root 'MySQL
server', click the back button of the beamer. Click the tab
'ACL Inheritance'. We consider this node as the root from the
semantic point of view, that is the root of MySQL Server access
targets tree, since the node '|pattern-name_bases sets|' does not
contain access targets. The second property in the tab is an
empty sorted list, since the root has no inherited ACL. The third
property, called 'Unsorted primary rights', is more interesting.
We call primary rights in MySQL, the rights on a target before
the selection of the applicable rights.
Click, on the left list of the
'Unsorted primary rights...' map, the key 'IO:: one:: tubun::
sqyl:: <U>:: jerry@localhost:: 0::'. At right, the
value 'USAGE' appears. As you may have noticed, this is another
kind to display our well-known ACL, always the same old ACL
'jerry >> MySQL server', but there, it is possible to get
its effective rights, and it uses a MySQL-friendly syntax!
Getting the effective ACL rights
means there is no key in this map if the ACL has no rights, or if
it has disabled rights. For instance, the first ACL into the
explorer (<G>:: anonymous§@%:: >> MySQL server:: ||
grant) does not produce any primary right, because this ACL has
no rights.
The 4 current keys of primary
rights ends with '0'. This number means they come from the direct
AclEntries of the current Resource 'MySQL server'. To compare the
same list, Click the node 'BASE One' in the explorer, that is
the first child of 'MySQL server'. The beamer displays a
larger list, where:
the 4 previous primary rights are
included, but ending with '1' rather than '0' (and all is OK!),
2 other primary rights ends with
'0'.
This explains the title of this
map: 'Unsorted primary rights at each parent level – The level
is the key ending number'. For the Resource 'BASE One', the
Resource 'MySQL server' is the parent having the level '1'. The
primary rights map summarizes all
the direct ACL on
the current node – with a key ended with '0' - and all the ACL
from any direct or indirect parent delivering
some inherited AclEntries of
the current node.
This is an Access Road property to
help the user. The term 'primary rights' is unknown in the MySQL
Server documentation. The primary rights represent an
intermediate level between the original ACL and the effective
rights of a couple (right user, access target). By the way, it
would also great for the user to have a look on how the MySQL
server selects the applicable statements for a given couple
(right user, access target). Let's study another list in this tab
'ACL Inheritance'.

This is the sorted list of the
inherited ACL on the base 'BASE One', from the parent 'MySQL
server'. No ACL rights there, since the important thing is the
order of the sorting. Click the beamer on the back button (to
display 'MySQL server'), then on the tab 'ACL'. How strange.
it is the same list! The direct ACL list on the root has been
simply copied into this property of its child 'BASE One'. Click
the tab 'ACL Inheritance', then, in the explorer, click the node
'Products table', the direct child of 'BASE One'. 'Products
table' has a first sorted list where the 8 first ACL are also
copied from the root 'MySQL server'. The 3 other ACL are copied
from the direct ACL list of its direct parent 'BASE One', as it
is visible in their names.
The sorted list has the title
'matched ACL at each parent level: user@host or
accounts-for-hosts or...'. This tries to recall the complex rules
used for the selection of rights by the MySQL Server. First,
about the term 'accounts-for-hosts' in the title of this sorted
list of ACL, keep in mind that the groups 'jerry§@local%' and
'jerry§@%' have the type 'pattern-name_accounts-for-hosts
group'. We will study the 'pattern-name' entities along with the
Access Road full views. We introduce now the selection of rights.
It is based on our well-known example.
When the account 'jerry' requests
an access to MySQL server, we see in the last list of ACL –
remember they are coming from the direct ACL of the root – that
it seems to have 3 matched statements for 'jerry':
<U>:: jerry:: >> MySQL
server:: || grant || localhost,
<G>:: jerry§@local%:: >>
MySQL server:: || grant,
<G>:: jerry§@%:: >>
MySQL server:: || grant.
Three selection rules are the
ground of all the access controls into the MySQL Server. They
take the following forms:
MySQL
Selection Rule 1:
for
a given level of parent, the MySQL server selects only one
applicable right statement (one ACL in Access Road), and it is
always the first one to match.
Of
course, the administrator cannot change the MySQL Server sorting
rules on the right statements. This means, for this example, that
the first sorted ACL 'jerry >> MySQL server' will deliver
its rights to the account 'jerry' on 'localhost'. For this
account, the two other ACL will never be used until the first ACL
is deleted! The 'MySQL server' ACS provides a precise sorting of
the AclEntries to simulate this MySQL Server behavior.
MySQL
Selection Rule 2:
Global
rights are on the root 'MySQL server' into Access Road.
MySQL
Selection Rule 3: for
a couple (right user, access target), the MySQL server adds all
the applicable rights at each parent level. This
means the 'jerry' rights on, say, the target 'Products table',
are simply the sum of the 3 sets of applicable rights on the root
'MySQL server', on the base 'BASE One' and on the target
'Products table'. The 'MySQL server' ACS handles the direct ACL
and the inherited ACL to simulate this MySQL Server behavior.
Note 1: to take account of the rule
2, when a right statement is set on any server component like a
base or a table, as a help to the administrator, the MySQL Server
and Access Road create automatically a global 'USAGE'
right on the server, for the same couple (user, host), if there
is no such right. Then, the new right statement becomes
effective.
Note 2: do not try to find these
selection rules in the MySQL documentation. They are never
presented into such a clear and short text...
We thank you to have been very
patient, learning MySQL rather Access Road! Now, by the way of
the Access Road full views, these 3 MySQL rules will be
illustrated quickly.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Three-hours
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
Creating an Access Road full view
The
full view is the main Access Road tool for simulating rights and
relations between objects, to display and to explain them.
A full view contains from 0 to 48 objects. The view objects are
always coming from the open ACS. The aim is to detect
all the access paths, if any, between each couple of
objects in the view. The full view provides the functions
to display the paths in two forms: a diagram and a text.
An access path between
two nodes is called simple or direct when there is no
intermediate node. A path may be indirect with a number of
intermediate nodes up to 40! The view text is the support and the
reference to explain in details the results of the view diagram.
For each access path, the text describes the nature of each link
for each pair of connected nodes.
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 'sqyl' and 'jerry' in the two fields, then click 'OK'.
The
third dialog appears to select the initial objects of the new
view. The 3 empty lists are respectively for displaying the
EligibleParties, Resources and VirtualFolders the user may select
in the explorer.
In
the explorer, click the UserID 'jerry' and the 2 Resources 'MySQL
Server' and 'BASE One'.
If a selected object is both an EligibleParty and a Resource, it
appears in the two relevant lists in the window. This is not true
for these 3 objects. If you make an error, the button 'Remove in
list(s)' should be used to deselect, for the new view, an object
which is currently selected in the dialog window.
When all is OK, click
on the 'OK' button.
The view 'jerry in the set sqyl' appears as a diagram in the
right bottom coin of the main window. With the mouse, increase
the size of the view window. In the view diagram, click
the nodes, drag&drop them to obtain the following result:

After the creation of a view, the explorer displays it as a node
under 'Full Views'. The beamer displays its properties. They are
very simple. The property 'Elements & comments' shows the ACS
objects and the textual comments of the view. They are changed
with the buttons 'Select' and 'Remove'. These items are also
displayed in the explorer, under the view node.
One can remark the view nodes are drawn with distinct patterns.
There is one graphical pattern for each great type of ACS
objects: UserID (like 'jerry'), Resource and Directory (like
'BASE One'), GroupID, VirtualFolder and Actor. The name of an
object in the diagram is its name last component. It is not
possible to separate for instance the node 'jerry' from 'tubun'
to the node 'jerry' from 'sqyl'. This is why it is recommended to
put the ACS name in the set name of the view. On the other hand,
clicking the node in the view displays it in the beamer, to see
all the details.
All
the access paths between each pair of view objects are detected.
An arrow or a
line between two view elements means there is one or several
access paths between them. Nothing between 'BASE One' and 'MySQL
Server' means that there is no access path. An arrow means the
path is oriented, with a source and a target, so two nodes may be
connected through two inverse arrows. An arrow or line is
generally drawn with a text which explain very shortly the
rights, or a general relation like 'owns', between the two
objects. The rights may be ACS rights, as there, or generic
rights. Into this view, the two arrows are similar because the
two relations are from an UserID to a Resource.
Note: Generally speaking, Access
Road does not copy the internal algorithms of the software it
simulates, whatever the software. This is impossible in numerous
cases, since the simulated software does not model its concepts
exactly like Access Road does. This is sometimes prohibit by law.
Let's
compare this full view to the sketcher.
Use together the
keys Ctrl+k to open the sketcher. An
empty sketcher appears. Click
the node 'jerry' in the full view 'jerry'.
The
numerous direct links around the UserID 'jerry' are displayed.
This includes the two links in the full view, without the 'via'
text about the indirect paths. In
the view 'jerry', click
on the node 'BASE one' (if necessary, move the window cursor to
see the nodes at left). The
sketcher shows 2 nodes above 'BASE one', including the UserID
'jerry'. The difference is the sketcher rights from 'jerry' to
'BASE one' are 'SELECT EXECUTE' without '<via> ...'. A full
view shows all the access paths, as we will see, while the
sketcher shows only the direct ACL, not the inherited ones. The
sketcher is simply useful to have a look, and to jump from object
to object through the network of simple relations.
The explorer displays the types
of ACS right for the MySQL Server. The
greater rights are displayed first.
Click the MySQL right 'SELECT' in the explorer.
The beamer displays, for this right, the comments 'Authorize to
SELECT rows on TABLE, COLUMN or VIEW', to summarize the meaning
of 'SELECT' for the MySQL Server. This right may be applied to
all the tables, columns and views of 'BASE One'.
Access Road handles a full view only if all the ACS objects are
from opened ACS. When the user closes an ACS, the open views
having objects from this ACS are closed without view saving. In
the same way, the closed views are checked when an ACS is removed
definitely from the Access Road base.
The view saving covers the list of the elements in the view, the
location of the view diagram window and the 'See Why' window in
the Access Road main window. The view saving keeps also the
relative positions of the nodes in the view diagram. The opening
of Access Road restores the last saving of the open ACS and the
open views, with all the open internal windows like the IS
Structure, the sketcher and the beamer. At the opening of a view,
if a view element is from a closed ACS, a message informs the
user and the view is not opened.
The reading of a diagram is very
intuitive. The objective is to offer a 'smart' reading to the
eye. If there is an arrow from A to B and a second arrow from B
to C, then this means, by default, there is an indirect access
path from A to C. If such an indirect path is not true, the view
has to inform the user. There is a simple drawing coding for the
links into a diagram. They may use the following formats:
a
black
arrow
is
an usual format for displaying the rights,
a
blue
line
indicates
a structural link, like for instance when an UserID is member of
a GroupID,
a
dashed-line
arrow
( - - - ) indicates
a weak link ('<WEAK> in the 'See why' text'); this means
the context of this link is not complete, like for instance when
a GroupID has rights on a Resource, while its applicable rights
are never used without the knowledge of an associated UserID,
a
double-lenght-line
arrow
( === ) indicates
the opposite of a weak link; this means the effective relation
between the two nodes is the direct one, while all the indirect
paths does not deliver false structural relations, but deliver
false rights,
some most complex cases require to
comment the path in the 'See why' text; they are outside
the scope of this tutorial.
Note:
The view diagram displays the right names as they are in the
relevant ACS. There are few exceptions for some generic
administrative rights, like for instance
'|transfer_limited_rights|'.
For these rights, the view diagrams display always the generic
description of the right, and not the ACS-specific term, while
the 'See why' text keeps the ACS-specific term.
The views are fully independent. 2 views may have exactly the
same items. Let's see now what is the 'See why' text of a full
view, and what exactly means, in the view diagram, the term
'<via>' in the text of an arrow.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Three-hours
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
The 'See why' text
of an Access Road full view
A full view explains all the access paths, using both an
universal vocabulary and some ACS-specific terms. This is the
role of the 'See why' window.
In the
view 'jerry', click
on the 'See why' button.
A new window
'sqyl:: jerry:: 'See why' text' appears. Access Road generates
this text after searching of the access paths. The middle of the
text is displayed hereinafter. We analyze it in details.
Each arrow or line in the view diagram is commented in a section
which starts with 'FROM A RIGHT USER TO AN ACCESS TARGET'.
Another headers are possible, like 'FROM AN USER TO A GROUP'.
Most of the visible text is
about the relation from 'jerry' to 'BASE One'. These names
are written in blue.
The generated text informs us there
are 3 access paths, numbered from 1 to 3.
The first access
path is direct (no intermediate node). It comes from an ACL link
which gives the rights SELECT, USAGE and EXECUTE. This path
explains the main result in this view and in the sketcher, for
the couple (jerry, BASE One). One may remark the rights for the
couple (jerry, MySQL server), into the direct access path, are
quite different, with only USAGE.
We study this first
path. It contains a lot of information in a condensed form:
ACL: there is an ACL
relation; a link between two nodes may contains several
relations,
SELECT; EXECUTE; USAGE:
they are the rights from the direct and indirect ACL on the link
second end (the access target 'BASE One' there),
(Current User: (jerry,
localhost): this tells 'jerry' is logged under this couple
(user, host); the MySQL server should for example attribute
(jerry, %) as the current user under which 'jerry' gets its
rights (the term of 'current user' is from MySQL),
<inherited ACL> :
this is a tag to signal there is at least one inherited ACL; a
link may show inherited ACL from direct or indirect parents,
<conditional ACL> through
localhost): this tells there is at least one conditional ACL
among the direct or inherited ACL, and it uses 'localhost' as
condition group; several condition groups are possible for MySQL
through several conditional ACL,
-- All Rights: SELECT/EXECUTE:
this summarizes the effective rights; we see that 'USAGE' has
not been kept, because this right is included into the 2 other
ones.
Generally
speaking, another use of this final description of the rights is
when there are several kinds of relations (ACL, membership,
owning, privilege...) to sum up, or when there are positive and
negative rights to subtract (this latter case is not possible
into the MySQL server ACS).
This range of information about an access path is mainly provided
by the generic features of Access Road. The specific code of the
'MySQL Server' ACS adds only two items: Current
User: (jerry, localhost) and
<inherited
ACL>.
The results are consistent in the diagram view and the 'See why'
text. However, the diagram cannot display all the rights whether
the words are too large. It displays the sum of the rights, with
the direct rights first. This is why the diagram displays, for
this link, 'SELECT EXECUTE' without 'USAGE'. The pattern '…' in
the diagram tells there is no place to write the last rights. If
there is enough room, the diagram displays after '<via>'
the applicable indirect rights, that is get through indirect
access paths. Like for the direct rights, the sum of the
indirect rights is shown.
The
second path from 'jerry' to 'BASE One' contains 2 intermediate
nodes: 'function_one'
and 'tom'. Between
each pair of nodes in the path, there is a numbered link, like
'Link number 2: Runs Under' from 'function_one' to 'tom'.
In this second path from the account 'jerry', some rights are
delivered through the account 'tom'. In the link number '1' of
the second path, the generic comment '<Sets Owner>'
indicates there is a jump to the Account/Groups context of the
Actor 'function_two'. 'tom' is the UserID under which
'function_one' runs as a stored function. This means that the
initial current user 'jerry@localhost', with the MySQL syntax,
has the rights to execute 'function_one', and this stored
function runs under the UserID 'tom' which delivers to
'function_one' some ACL rights on the base 'BASE One'.
In a condensed form, this second path may be represented by the
expression 'jerry/ acl/ function_one/ runs_under/ tom/ acl/ BASE
One'.
This result simulates the so-called DEFINER mode into MySQL
Server. It is supported by a generic feature of Access Road. It
is also able to simulate, in a Linux Ubuntu, the behavior of a
program starting under a given account. This is an example of how
Access Road finds all the programs which, from a given UserID,
allows to run into the context of another privileged UserID, like
'tom' there.
It
may seem strange to declare that 'function_one' has rights on
'BASE One', while we don't know what this function done, and it
may never use these rights. Generally speaking, Access
Road simulates what the software MySQL Server 'knows' about its
components and their access controls, and not the effective
executing paths through the active components. The
aim of access controls is to selectively control what each
component is authorized to do. A very good precaution in IT
security is to have no confidence on any program, to not suppose
it makes only and strictly what it is supposed to do, like
'function_one' there.
Save
your current work through the command File → Save All (Ctrl+s).
The 'See why' text may be
selected and copied into the desktop native clipboard of the
operating system, to let the user copies it into any application.
Access Road displays now, into its main window, a view diagram
window and a 'See why' window for the full view 'sqyl:: jerry::
'. It is possible to open several full views, and to group them
in one window: Select in the main menu, the command
Window -> All Full Views (Ctrl+m).
The two full view windows of
'sqyl:: jerry:: ' disappear. They are replaced by a central
tabbed 'Full Views' window.
When this window is opened, each current or new open view is
displayed in a dedicated tab. The view diagram is at the top, and
its 'See why' text at the bottom. The only difference is about
the colors: the 'See why' text is fully written in Black.
An open view in the GUI is visible in the explorer. It may be
without displayed diagram nor 'See why' text. This allows to open
numerous views without filling the main window uselessly. When
the menu command 'View diagram or ACS tree' is used while an open
view is selected in the explorer, the view is placed into a new
tab of the 'Full view' window if it is open in the GUI.
Otherwise, the diagram is put in its own view main window, like
our first example at its creation. In all cases, the diagram and
the 'See why' text of a view may be closed while the view remains
open in the explorer.
Let's
now have a look on how the 'See why' text describes the access
paths, whatever the ACS, as varied relations or rights. As 'ACL'
there,
'Runs Under', 'Is Member', 'Owns', 'Contains' and 'AGO Other
rights' are varied link types among others. The point is the
link type tells what object properties to consult in the beamer
to
study a given relation or a right. The
Access Road glossary helps to link
the vocabulary of the 'See why' views to the vocabulary of the
beamer.
In the explorer or the view,
click 'BASE One', then in the beamer, on the tab 'ACL
Inheritance'.

The image shows the primary rights
map of 'BASE One'. The selected key ends with '0'. The values
'SELECT' and 'EXECUTE' in the map explain the rights get from the
direct ACL on 'BASE One', as the view has found them. After this
section, we are able to create and understand a full view. In
this example, the 'See why' text also demonstrates how an Access
Road view fulfills with the 3 basic MySQL rules about access
controls, as they are presented in the section 'Introducing the
MySQL ACL'.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Three-hours
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
The updating of an Access Road full
view
We create now a second full view,
for Linux Ubuntu objects, to make a quick test. First, we return
to the display mode of independent windows for the full views:
Close the 'Full views' window. A dialog appears to close
all the open full views. Click 'No'. The view 'sqyl::
jerry' remains opened in the explorer.
Follow the creation procedure of
a full view, with 'tubun' as set name and 'any' as view name.
Select for the view, in the explorer, exactly 12 'tubun'
objects of your choice, including both UserID, GroupID and
Resource objects.
The user would see during few
seconds a message 'Please wait', while Access Road detects all
the access paths of the view. The new view diagram should appear
as a unreadable network of links! Enlarge the diagram window,
and try to drag&drop some nodes to get a clear presentation.
An hidden grid defines the allowed positions of the nodes.
If the number of links is too
great, it is not easy to get a clear presentation. If a node is
dropped on a location the diagram forbids, there is no move.
Access Road uses for the full views a layout of the allowed
locations that depends on the number of nodes. The range of
locations is squares of 4x4, 5x5, 7x7 or 10x10 node locations. Up
to 7 nodes, the view diagram uses a layout of 16 possible
positions. A diagram of 12 nodes is displayed in a layout of 25
locations, while a 13-nodes diagram uses a layout of 49 possible
locations. To have a better diagram, it is possible to enlarge
the layout by an adding of object: Select in the explorer a
new object for this view (if necessary, click in the explorer the
view node 'tubun:: any'), and click into the beamer the 'Select'
button of the property 'Elements & comments'.
This dialog appears to add a view
object or a comment.
Select 'Object to select' then
click 'OK'. A new dialog
appears for a selection an object in the explorer. Select
the object.
The object of your choice is added
at the top left of the diagram window. It is recommended to move
any new node immediately, to let empty this place for the future
additions.
The good new is Access Road has
just selected a layout of 49 locations for this diagram. The
nodes would be more easy to be well positioned, getting a clearer
network of links. To try to clarify the diagram, enlarge the
view window and try to drag&drop some nodes to the bottom of
the diagram. Of course, if the number of links is too great,
the diagram will stay unreadable, even if the 'See why' text is
always workable. The best choice is then to get less nodes in the
diagram. The view may be cut in two complementary views.
Note 1: When a view node is
removed, the positions of the other nodes may change into the
full view diagram, because the layout has also changed.
Note 2: A new view node is added at
the top left coin of the diagram, but sometimes it is not alone.
It is necessary to add a second element when there is a hard
alias relation. An example is a MySQL view, which is modeled
as an Actor being alias of a Virtual Folder. When the user adds
to a view one of these two components, the second element is
automatically added by Access Road in the bottom right coin of
the full view diagram.
Save your current work through
the command File → Save All (Ctrl+s).
Close the diagram of the second
view 'tubun:: any'. Click 'Yes' in the dialog window, to
close this view.
We will discover now one
of the most powerful feature of Access Road. It updates
immediately an open view at any change in the base which modifies
the results of the view. This is true for example when the
rights change in any implied ACL, or when an UserID is no more
member of a GroupID.
We use the first view
'sqyl:: jerry' to test the MySQL selection rules. For
a given level of parent, the MySQL server selects only one
applicable right statement (one ACL in Access Road), and it is
always the first one to match.
The
idea is to delete the matched global ACL 'jerry >> MySQL
server', to see how the rights change in the view. An ACL is
created and deleted through its target ('MySQL server' here).
In the explorer, select the
first view 'sqyl:: jerry', then use the command Window → View
diagram or ACS tree (Ctrl+u). The
diagram and the 'See why' text are opened.
Click in the view
diagram the node 'MySQL server', then in the beamer, click the
tab 'ACL'. Into the sorted list of ACL, select the ACL from
'jerry' ('<U>:: jerry:: >> MySQL server:: ||
grant || localhost'). Click the list button 'Delete'. Confirm
the command.
When the view has very complex paths, the updating of the access
paths may need several seconds. The user has a message in Blue
'Please wait...' at the top left coin of the diagram. But this
should not be here.
The view 'sqyl:: jerry' is updated, both its diagram and its 'See
why' text. In the diagram, deleting the ACL has replaced the
direct rights 'SELECT' and 'EXECUTE', from 'jerry' to 'BASE One'.
Here is the updated 'See why' text:
The resulting text is fully changed. The rights of 'jerry' on
'BASE One' is now CREATE (it includes USAGE). The current user is
no more (jerry, localhost) but (jerry, jerry§@local%).
CREATE is delivered by a direct ACL on 'BASE One': '<G>::
jerry§@local%:: >> MySQL server:: BASE One:: || grant'. It
is easy to check it through the beamer, when 'BASE One' is
selected in the explorer, as we have seen in the section
'Introducing the MySQL Server AclEntry'.
Note:
when a global right statement is deleted, the MySQL Server
deletes all the similar statements at the other levels. This
behavior is reproduced by the 'MySQL server' ACS. This is why
deleting the global ACL 'jerry@localhost'
has produced a deleting of the second ACL 'jerry@localhost' on
'BASE One'.
Reading
a diagram is very intuitive. An important property is to offer a
'smart' look to the eye. Whatever the
choice of elements in the view, the overall meaning has to be
stable. Let's take an example. The new rights are get through the
strange group 'jerry§@local%'. What about the diagram, if this
group is added to the view?
Click in the explorer the view 'sqyl:: jerry'. In the beamer,
on the property 'Elements & comments', click the 'Select'
button, click 'Object to select' in the dialog box, then click in
the explorer the 'sqyl' GroupID 'jerry§@local%'. The
view is updated. Enlarge the diagram window and move
the nodes to get this result.
Each path is commented with a text starting near the source of
the path. There are 2 inverse paths between 'jerry' and
'jerry§@local%'. The text 'member of' is near 'jerry', so
'jerry' is the member of the group.
The first look shows no link between 'jerry' and 'BASE One'.
However, 'the user eye' may find an indirect path, because
'jerry' is member of 'jerry§@local%'. A membership, as the other
structural relations, is shown with a blue line rather than an
arrow. 'jerry§@local%' has a CREATE right on 'BASE One' (this is
a black arrow). Then, 'jerry' has a CREATE right on 'BASE One'.
With or without the group 'jerry§@local%' in the view, the
overall result is exactly the same.
The last state of the view shows us a new property of MySQL
Server for a pattern-name group like 'jerry§@local%'. This
GroupID contains automatically and uniquely all the accounts
having a name with the form 'jerry' or 'jerry(x)' (whatever the
character 'x'), and belonging to any host having a name with the
form 'local%'. '%' is for MySQL Server a wild-card meaning 'any
sequence of characters'. This is why 'localhost' matches as a
host. The 'See why' text describes the link from 'jerry§@local%'
to 'BASE One' without current user, because it may be used by any
member of this group, and not only by 'jerry'.
Note: if you know how MySQL Server works, you may remark the
group 'jerry§@local%' is the equivalent to the MySQL right
statement 'jerry@local%'. The difference '§' is specific to
Access Road, to ensure an account has only one first simple host.
There is a strange path from 'jerry@local%' to 'jerry', in other
words, from a GroupID to an UserID. The diagram shows the text
'<via> inti contxt' for this path. How a GroupID could have
an access path to an UserID? In the glossary, the term 'init
contxt' is explained like this:
“In
a view, when there is an access path to an Actor starting under a
given UserID or GroupID context, this
actor runs under this UserID or GroupID,
as component of the proper Account/Group context of the Actor. A
relation 'Run under' is created in the view from the Actor to the
relevant Account (in other words, UserID) or GroupID. This
relation is displayed in the view diagram as a line with the
comment 'init
contxt' (for
'initial context'). When an Actor is executed directly, its
default AG context is overridden by the received AG context into
the access path. However, for
some specific cases, the current AG context of the path may be
switched to the Actor default AG context.
As a generic behavior, this default AG context is applied only
when the Actor is the first end of an access path, or when it
receives a call through its ExchangePoint. The specific cases are
found among the ACS addon Actors, like ExecutableUbuntu in the
ACS addon Ubuntu, or the DEFINER mode in the ACS addon MySQL.”
We have here 2 examples of the DEFINER mode of MySQL, for a
trigger and a stored procedure (2 kinds of MySQL Actors). This
means it is possible, for a member of the GroupID 'jerry@local%',
to get a kind of execution in the context of the UserID 'jerry'.
Of course, this execution is controlled by the Actor that is the
intermediate node in the path. The 2 paths from 'jerry@local%' to
'jerry' are described into the 'See why' text as, in a condensed
form:
jerry@local%/ acl/ trigger_one/ runs_under/ jerry, and
jerry@local%/ acl/ procedure_one/ runs_under/ jerry.
How is the diagram if the 'natural' indirect path through a node
is indeed forbidden? If there is a direct path from 'jerry' to
'BASE One' that forbids the current indirect path via
'jerry§@local%', then this direct path is drawn in a
double-length-line arrow. It is then the only applicable path. To
see such a simple unique path, let's return to the previous state
of 'sqyl'!
Create
the new ACL 'jerry@localhost'
on 'BASE One', with the rights SELECT and EXECUTE. The procedure
to follow is from the first
tutorial. Simply keep in mind that the right user to
select is 'jerry', and 'localhost' is the conditional group to
choose (caution: a 'jerry' ACL without conditional group may be
created on the directory modeling a MySQL base, but the result in
the view would be different).
The
2 double-length-line arrows forbid the indirect paths.
This means 'jerry§@local%' can
no more be an intermediate node from 'jerry' to access to 'BASE
One' or 'MySQL server'. On the other hand, this group keeps its
own accesses, and some of its members, except 'jerry', may have
to use them. In a such a case, the 'See why' text displays, for
the paths from 'jerry' to 'BASE One' and the path from 'jerry' to
'MySQL server', a
special comment 'Global <first rate link>' in the first
simple path. It is
the equivalent of the double-length-line arrow in the diagram.
Save your current work through
the command File → Save All (Ctrl+s).
To design access controls for the
MySQL Server, we cannot simply read a full view and take the
results without question. We have to master the rights sorting
and the rights inheritance management. Access Road is there to
help you.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Three-hours
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
About the MySQL Server design
This
tutorial does not study the MySQL Server privileges with the
vocabulary of MySQL Server. Its purpose is to handle the MySQL
Server access controls with the vocabulary of the MySQL Server
ACS addon, into Access Road. To connect the concepts of the two
worlds, let's see the guide
for this ACS addon.
In the next section, we
will see how to use the full views to define and verify the
design of the rights on a MySQL Server. There is already a
powerful and well-known free software called MySQL Workbench®.
It is able to design the access controls through administrative
and technical roles. Above all, it can inject the resulting
design, as right statements, into an instance of MySQL Server.
For
instance, it is quite easy to design, with MySQL Workbench:
a set of 3 separate database
administrative roles to attribute to the IT technical staff, the
good rights for the good task, at the global and base levels;
a set of 10 separate technical
roles to attribute to the 10 sets of applicative transactions
that have to access to the bases of the MySQL Server;
from a structure of MySQL bases
designed to well match to this set of MySQL technical roles, the
access controls are efficient, easy to design, to configure and
to maintain.
For simple and stable
needs of access controls, MySQL
Workbench is quite good. It is efficient for
managing the administrative roles. However, this tool has some
important limitations each time the MySQL Server contains complex
or unstable bases, or with fine-grained needs of access control.
It
does not cover the full range of the MySQL access control
features:
it cannot tell if a right
statement for 'jerry@local%' overrides or not a right statement
for 'jerry@%'; this means it does not allow to design a
differential naming space into the right statements, as we will
see Access Road help to do;
it cannot handle the rights at the
levels under the bases, like on a table, a stored procedure, a
view or a column; this means, for instance, it is not possible
to design a stored procedure, running under a specific secure
account, to provide a common high-security-level code to all the
applications accessing the MySQL Server.
Furthermore, MySQL Workbench does
not permit flexible strategies of access control. On the other
hand, Access Road is able to simulate all the strategies.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Three-hours
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|
Designing MySQL Server access
controls
with Access Road
First
strategy: administrative
and technical roles
This
access control strategy is simply derived from
the MySQL
Workbench ability to handle administrative and technical roles.
We
use the first access control form through proxies, seen in the
section 'Introducing the MySQL AclEntry'.
In
the explorer, click the UserID 'lp'. In the beamer, this UserID
has no 'ACL' tab, because it is a special type of UserID called a
Proxy, having no ACL. Click the tab 'Alias'. The
property 'Proxied account' shows that 'lp' has the account
'jerry' has alias reference. This means simply that 'jerry'
transfers all its rights on the MySQL Server to the Proxy 'lp'.
To
see it in Access Road, let's add
'lp' to the view 'sqyl:: jerry',
by the way of the known procedure. After a node moving, this
diagram is get.

For the link from 'lp' to 'jerry',
the 'See why' text gives the description:
'Is alias: PROXY; |modify_owner|;
-- All Rights: |modify_owner|/PROXY'.
The metaright '|modify owner|' is a
generic mark to indicate this link implies the change of the
active UserID, there from 'lp' to 'jerry'. The MySQL right PROXY
is dedicated to this type of aliasing. It cannot be selected in
an ACL for the directory 'MySQL Server'.
Note: This is an example where a
MySQL alias relation is not modeled as a true generic alias by
the generic code, but as a MySQL ACS addon relation which uses
the generic vocabulary of the 'See why' text ('is alias' and
'|modify owner|') to describe the relation. Reusing the generic
terms when there is an equivalence is a recommended practice for
all the ACS addons, like for MySQL there.
To
create administrative and technical roles, the
principle is exactly the same: the roles are proxied accounts
like 'jerry', and the easy administrative task is to tie the
proxies like 'lp' to a role, when the proxy is created. Into the
beamer, the account 'jerry' has a MySQL property 'Proxy
accounts', in the tab 'Members'.
Second strategy: differential
naming space into the right statements
This access control strategy is
based on the rights sorting of the host names. For instance, we
may have the following configuration:
an user desktop with a DNS name
'pc84.example.com';
in a space of 100 desktops named
from 'pc1' to 'pc100';
the MySQL Server host is put at
'sql.hosts.com';
there are application servers at
addresses from 'ap1.hosts.com' to 'ap5.hosts.com', and from
'ap6.main.hosts.com' to 'ap8.main.hosts.com'.
Such
a name space has to be modeled by Access Road as an information
system. The IS root is 'com' with a child 'example' having the
100 'pc' ACS as children. The IS name sets the components in a
reverse order. Creating such an information system is not
necessary there (how to do it is explained in the first
tutorial).
We create the Access Road
accounts-for-hosts groups named 'com.example.%', 'com.hosts.%'
and 'com.hosts.main.%'. Access Road fills up automatically the
group 'com.hosts.main.%' with the application server hosts
'com.hosts.main.ap6', 'com.hosts.main.ap7' and
'com.hosts.main.ap8'.
The rights sorting of MySQL Server
selects 'com.hosts.main.%' before 'com.hosts.%'. We have already
modeled a group 'jerry§@local%'. To see an example of such
rights sorting through the ACL sorting, let's create a new
accounts-for-hosts group called 'jerry§@localho%', then an
INSERT-right ACL on 'BASE One':
In the explorer, click the node
of the ACS 'sqyl'. In the beamer, click the tab 'Rights Users',
and click the 'New' button of the property 'Own Eligible
Parties'. Select 'GroupID' in the dialog window, then 'OK'. In
the creation dialog window, enter the name 'jerry§@localho%',
select the type 'pattern-name_accounts-for-hosts group' and 'no'
about the administrative role, then click 'OK' to create the
group.
In the explorer,
click the node of the Resource 'BASE One'. In the beamer, click
the tab 'ACL', and click the 'New' button of the property list
'Sorted list for users'. In the creation dialog window, select
'sqyl' as ACL manager, the new group 'jerry§@localho%'
as Right User, 'INSERT' as single right, no condition group, and
click 'OK'.
Access Road has
automatically set 'jerry' as member of the new group. The beamer
displays the new ACL. Click the beamer back button, to
return to the ACL tab of 'BASE One'. The new ACL appears at the
second position, as a choice of the MySQL ACS. It is selected in
this image:

The open view 'sqyl::
jerry' is not updated, since the first applicable ACL for 'jerry'
has not changed. To do it, we have to delete the first ACL in the
list:
In the beamer, click
the first ACL '<U>:: jerry:: >> MySQL server:: BASE
One:: || grant || localhost', then click the 'Delete' button.
Confirm the operation.
The view 'sqyl:: jerry'
is updated. The right 'INSERT' from the new ACL is used by the
link from 'jerry' to 'BASE One'. It is easy to see that the
second ACL of the list, at the level of 'BASE One', has not been
selected since its right is 'CREATE', and not 'INSERT'. This
means that a right statement for the group
'jerry§@localho%'
overrides a statement for the group 'jerry§@local%'.
We have here the basic mechanism of a differential name space.
Note: the 'See why' text
of this link shows the same previous selection as the 'Current
User: (jerry, localhost)', because the applicable ACL at the
global level of 'MySQL server' remains the
ACL '<U>:: jerry:: >> MySQL server:: || grant ||
localhost'. To change this behavior, it is possible to delete
this global ACL, so that the current user will become (jerry,
localho%).
To use a differential name space in the MySQL Server rights, the
principle is to have the same set of MySQL accounts as users from
all the application servers, both from 'com.hosts.%'
and 'com.hosts.main.%'. This is an useful
simplification. Since the 'com.hosts.main.%' rights are applied
when the account is from these 3 hosts, this is an efficient way
to deliver restricted rights to these hosts. For the other
'ap1.hosts.com' to 'ap5.hosts.com' hosts, greater rights are get
through the group 'com.hosts.%'.
Third strategy:
powerful dedicated accounts for secure routines
This access control strategy is
based on the DEFINER mode of MySQL Server. To complete the INSERT
right, we add an EXECUTE right on the new 'jerry§@localho%' ACL:
Click
this ACL in the explorer (caution:
Access Road has created such an ACL for the node 'MySQL server',
but we use there the original one, on 'BASE One'). In
the beamer, click the tab 'ACL', then on the button 'Select' of
the property 'List of rights'. In the selection list, select only
'EXECUTE', then click 'OK'.
This new EXECUTE right
allows 'jerry' to execute 'procedure_one', as the 'See why' text
shows. Running under the account 'tom', the launch of the
'procedure_one' gives to 'jerry' a new access path through the
account 'tom', connected there under (tom, localhost).
It is easy to set the
'tom' rights so that it delivers higher rights to 'jerry', but
only under the control of the 'procedure_one'.
It is possible to design a stored
procedure, running under a specific secure account, to provide a
common high-security-level code to all the applications accessing
the MySQL Server.
This is an usual strategy to
protect the most critical applications with the MySQL server
access controls.
Exit Access Road
Congratulations! The
time is over for this large tutorial.
If you have trouble with
the behavior of Access Road, do not hesitate to read this
tutorial one more time. Remember
that, as a processing, the core of the MySQL Server simulation is
the management of the ACL sorting, the ACL inheritance and the
pattern-name containers. However, MySQL Server is just an
example. The MySQL ACS addon represents less than 10 % of the
total Access Road 0.7 code. Most of the subjects in this tutorial
are generic, for all the simulations.
With the full
views, Access Road offers an unique tool for studying and
improving the design of access controls. It is based on
extended capabilities to display efficient images and texts, full
of levels, significance and knowledge, so that the true power
remains in the human mind!
Save your current work through
the command File → Save All (Ctrl+s).
The purpose of the next
tutorial is to show how a NoMore-NoLess view may help to verify
an access control policy. The third tutorial will also explain
how the rights for a pair (right user, access target) may be
negative, how the user identity is managed through a chain of
software, and how to import and export data. After the examples
of Linux Ubuntu and MySQL Server, this third tutorial will add
the example of a Role-Based-Access-Control application.
How
to exit Access Road is described at the end of this
tutorial.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Three-hours
tutorial for verifying access controls
Why
Access Road is unique
Glossary
|