Access Road 0.7.3
Glossary

Copyright 2000-2013 ACCBEE
The Access Road documentation is free. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation ; with the Invariant Section being "Introduction to Access Road".
A copy of the license is included in the section entitled "fdl-1.3". The author may be contacted at "Sourceforge".

A B C D E F G H I L M N O P R S T U V


A

Access Control Link

See Link.

Access Control System [presentation of concept]

Access Control System (ACS) is the most important concept in Access Road. This provides the simulation of a software that manages access rights in an information system (IS). An operating system, a firewall or a database management system are examples of such modeled software. A complex software may be simulated by several interconnected ACS. In most of the cases, one ACS is suffisant. An ACS is a component of an information system. It may contain the simulation of several relatively independent access control functions, like in the Linux Ubuntu ®, and this defines the concept of subACS. An ACS manages mainly right users and access targets. What are the managed concepts is the role of the ACS structure. Between its components, there are varied structural and non-structural relations as access control lists and membership. The types of right are modeled as Account/Group rights, Bridges, AclEntries or Privileges for delivering the effective StringRights to the right users into this ACS or outside this ACS.

Access Control List Entry (or AclEntry)

The access control list entry (ACL) manages some access rights (it is a positive ACL) or some access restrictions (it is then a negative ACL) from one eligible party to one resource. An AclEntry is conditional when it uses some condition group(s). For a given pair of (eligible party, resource), the AclEntries of an ACS are fully defined by two properties: the sens of the ACL rights (positive/ negative) and, only for a simple-condition ACL, the first condition group (See Conditional Access Control List). An ACL is created and deleted from its Resource. Its rights may be changed by the user after the creation, while its source and target are immutable. This is the inverse behavior of a Typed Privilege or a Linked Privilege. An ACL may be inherited from the Resource (in)direct parent. An ACL may be associated to several ACS. In the simplest case, the ACL, the eligible party and the ressource belong all together to the same ACS, and it is an internal ACL. Else, the ACL is external because the ACS of the source is not the ACS of the target. The most complex case is forbidden, when the ACL, its source and its target belong to three different ACS. The displayed name of an external ACL starts with the name of its ACS. An ACL contains one or more rights which follow the rights list managed by the ACS which manages this ACL. Note: if the concept of AclEntry is applicable, an access control may be simulated by the mean of an instance of AclEntry, even if 'ACL' is not the term used in the simulated software. For instance, in the MySQL Server, the AclEntries are called 'privileges' from the MySQL user point of view.

Access target

An access target is an entity which has the capacity to be accessed by a right user, if the ACS allows it. A Resource is an access target in most of the cases, when the ACS policy allows it to its resource type. A groupID is always a right user, but may be an access target for its group members and for the actors which run under it. An ACS may be an access target for the other ACS.

Account/Group rights (or AG rights)

The Account/Group rights on a Resource are the most complex ones. They include first the rights for the UserID (or account) which owns a Resource. The rights may be ACS rights and generic rights, positive and negative rights. The negative rights are subtracted from the positive rights. The ACS policy on 'OwnerRights' is an exemple of policy, and it sets the permissible account rights. The AG rights includes also the rights for the main GroupID owning the Resource. These rights are delivered to any active member of the GroupID which owns the resource. There are inherited AG rights in the core functions of Access Road, from a Directory to its Resource children. An Actor may have a current account and a current group under which it runs, and this feature may deliver AG rights to this actor. The AG rights are always internal rights for a given ACS, while it is possible to have external AclEntries or external Linked Privileges.

Account/Groups context [presentation of concept]

This is an internal property of an access path, for one node of the path. The AG context is defined as a set of GroupIDMembers under which a path node works, taking account of the previous nodes in the access path. For instance, the second tutorial of Access Road explains how the 'See why' text of a full view may show an access path handling an Account/Groups context. This is an extract of the tutorial : “the generic comment '<Sets Owner>' indicates there is a switch under the Account/Groups context of the Actor 'function_one': '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 very condensed form, this second path may be represented by 'jerry/ acl/ function_one/ runs_under/ tom/ acl/ BASE One'. This is a generic feature of Access Road, able for example to simulate, in a GNU/Linux Ubuntu, the behavior of a program starting under a given Account/Groups context. The Account/Groups (AG) context is also used in an access path to apply, or not, the rights of a conditional AclEntry on the Actor which is the ACL source. The AG context of a node in an access path is a list that may contain, first, an optional couple (UserID, GroupID), second, a list of optional GroupIDs of the same ACS, and third, some UserIDs and the GroupIDs of another ACS which are the AG context of previous nodes in the access path. The typical role of a ContextSwitch is to select the local AG context for a given income stream (as access path) in its ACS, following the AG context of the previous nodes in this access path (new in 0.7.3). See also 'initial context' and 'received context'.

Actor

Servers and programs are typical actors in an information system, for the Access Road simulations. An actor is an acting resource which, as a kind of eligible party, may access to other resources controlled by an ACS. It may run under a given UserID and a given GroupID. If it started under them, they are its initial AG context. It may also run under some secondary actor groups. It may play some special roles, as a bridge, between an another actor and some resources. Actor is the top-level entity which is both a ressource and an eligible party. ExchangePoint, ACSReferral and ContextSwitch are types of Actors (new in 0.7.3). They help to model the exchanges between the programs in an ACS, and also between the ACS. As any ressource, an actor belongs to one ACS which controls it, and it may be controlled by other ACSs by the way of external AclEntries or external Linked Privileges. For these ACS, it is shown in the explorer as an external controlled actor. As any eligible party, an actor may also have access rights on ressources that are provided by other ACSs. For these last ACS, it is shown in the explorer as an external eligible actor An Actor may be set as being a no right proxy. An ExchangePoint (new in 0.7.3) is an Actor having some reduced maximal rights for its master program (see proxy as feature of an actor).

ACS addon

An ACS addon allows a developer to add easily to Access Road some Java classes for implementing new ACS functions, beyond the generic features of Access Road. Linux Ubuntu® and MySQL® are exemples of ACS addons. An ACS addon provides a dedicated guide (menu Help/ACS addon guides). The advanced user can create by hand a new ACS from the properties of an open ACS after its creation by an Addon, as it is possible to do from a generic ACS. However, the user has to make only ACS property changes that have been approved and documented by the ACS addon editor. An ACS addon is not a true plugin, because the current ACS addons are detected by Access Road at its starting, and the list of ACS addons cannot change during the program execution.

ACS policy

The simulation of a software by an ACS requires to define its behavior, as a complement of the software structure. This definition is done in Access Road by the ACS policy. It is set at the creation of the ACS, and then it cannot be changed. For instance, the type of objects it is possible to create from a given ACS directory, is defined first in the structure (as 'actors are managed'), and secondly, in the ACS policy (as 'this type of directory may have actors'). In the beamer displaying an ACS, the ACS policy is shown through the properties of the tabs 'Types', 'Actions', 'Rights' and 'Rights 2'. A policy checksum allows to check the identity of the ACS policies (new in 0.7.1). The third tutorial provides an introduction to the ACS policy. To see all the properties in an ACS policy, let's read the Javadoc documentation of the class ARoad0.gBase.ACSImpl, and its methods getM_TypeOrientedPolicy and getM_TypesAndGUIPolicy.

ACL link type

This is an access control link type, which defines the relation based on an Access Control List.

ACL rights inheritance

This is a main ACS structure property to set the AclEntries are inherited in the resources tree.

AG inheritance

This is a main ACS structure property to set the Account/Group rights are inherited in the resources tree.

Alias of

This link type is used for varied cases. There are first the soft aliasing and the hard aliasing an ACS may manage as main structure properties. An ACS Addon may also handle some 'alias' relations without setting the generic methods of search. Such an ACS Addon handles by itself the 'alias' relation. For instance, the ACS Addon MySQL uses an 'alias' relation from a ProxyMySQL and its reference, that is an UserIDMySQL. This is similar to a generic soft aliasing that the ACS Addon MySQL uses only for the external links to the Ubuntu roots. Finding this relation is the responsability of the ACS Addon MySQL.


B

Beamer in the GUI

The beamer window displays the structure and the properties of a selected object in the explorer. Each object has a specific set of properties. The beamer changes its display to show the properties each time the selected object changes in the explorer. A given ACS may specifies some small adaptations for displaying its proper objects. An ACS addon may add its proper rules and terms. The beamer is the unique window to update the Access Road objects. The only exception is for the creation and the deletion of an ACS or a view, where the operations are done through the main menu (File/New and File/Remove). The beamer always displays the current internal state of the selected object.

BRIDGE link type

This is an access control link type, which defines the monodirectional relation between two Actors from different ACS, where one actor is the source having an access to the bridge target.


C

<Caution: no indirect path through>

This Global comment is displayed by a view on a DisplayableLink to inform about the danger to wrongly interprete some indirect paths between two nodes (new in 0.7.3). The normal way of reading a full view having 3 nodes (A, B, C) and 2 paths (A to B) and (B to C) is to see an indirect path from A to C accross the node B. This is a 'See why' view comment to say that this interpretation is false in a precise case. This occurs when a set of nodes in the view (say, B in the simplest example, but a chain of nodes is possible) delivers indirect access paths, for a couple of other view nodes (A and C in the example), which are not fully defined by the reading of the indirect paths through the set of nodes. Typically, the AG context switching from a context switch is undefined when the access path starts with this context switch. Any switching depends on the AG context before this context switch in the path. Access Road creates then a direct access path from A to C to precise the effective relation. The current paths A-B and B-C have the comment 'Used in indirect paths'. Such a view node with undefined or unclear rights may be an exchange point or a context switch, or, for an ACS adddon, it may be another node. After the comment 'no indirect path through', and for these other view nodes (B, in the simplest example), Access Road adds the ends of the name of the first implying node of the chain. They are the last two name components of each node, separated with ':: '. Two view nodes are separated in the comment with '||:: ', like 'dir:: tom||:: mysqld:: mysqld.sock||:: '. See also the comment 'first rate path'.

<Caution: to subtract to indirect paths>

This is a GLOBAL comment to say, for a simple DisplayableLink, that its rights are the result of a subtraction, while they are some indirect paths on which the rights subtraction has not be performed. The effective global result depends on the policy of the ACS. The generic behavior is to subtract all the negative rights to all the positive rights, like in a view containing only the two ends of this displayable link.

CONTAIN link type

This is an access control link type, which defines the relation between a GroupID and one of its member.

Conditional AclEntry [presentation of concept]

A form of Access Control List which is workable only if the ACL eligible party (or source) is the direct or indirect member of each GroupID into the ACL condition list (so-called the condition groups), or, if this ACL EP is an Actor, if its Account/Group context is a direct or indirect member of each condition group. There are two types of conditional ACL: the simple-condition ACL and the right-condition ACL. This defines two structural properties of an ACS. In a simple-condition ACL, the user sets exactly one immutable condition group when it creates the ACL. In a right-condition ACL, the condition groups are defined through the choice of the conditional rights of the ACL. For instance, the Linux Ubuntu ® simulation of the authorization system uses conditional rights like 'Authorize<IF>Console', when the eligible party is a Linux UserID. This produces for the ACL a condition group 'Console', that is the name of a GroupID in the Linux Ubuntu ACS. This ACL has then enabled rights only if the ACL UserID belongs to the GroupID 'Console'.

In the case of an Actor as ACL source, it is not possible to the AclEntry to 'know' what is the current Account/Group context of this Actor. This is a case where the ACL enables its rights, and the responsibility of the access path search is to use or not the rights of this ACL when the AG context of the ACL Actor source has been defined. The list of condition groups may be empty only in a right-condition ACL, and after an user updating of the conditional rights. In that case, the ACL rights are always enabled. An external ACL may be a conditional ACL, and then, the ACS of each condition group has to be the ACL source ACS or the ACL target ACS. Only the internal right-condition ACL allows several condition groups. An external ACL may be conditional. Then, it cannot have more than one condition group, and this group has to belong to the ACS of one of the two ends (it may not be the ACL ACS).

Conditional Right

An ACS Right which is associated to one or several groupIDs of its ACS. Example: 'Authorize<IF>Console' is activated (in other words, 'Authorize' is an effective right) only if the access source belongs to the groupID 'Console'. It is handled in a conditional AclEntry.

Context Switch

A kind of Actor which is an EndPoint for modeling the context switching feature of an ACS (new in 0.7.3). The context switch properties are displayed by the beamer in the tab 'As Switch'. A context switch receives the income stream, modeled as an access path coming from another ACS, and it selects the local context for this access path. Typically, the local context is the Account/Groups context under which this ContextSwitch runs, giving the AG context of the income stream from the another ACS. ExchangePoints and ContextSwitches help to model the exchanges between the programs in an ACS, and also between the ACS, to simulate the integration of the access controls. As a data exchange point, a context switch is able to set an access control on the names of the senders, by the way of white and black lists. As a special Actor, a ContextSwitch is limited, both as source and as target, on its AclEntry, bridge and linked privileges rights.


D

Data Exchange

This is an access control link type, which defines the relation between 2 processes which may exchange some data. An example is between two IP network sockets. These rights may be constrained by the reduced maximal rights of a data exchange point. This is a weak link. Without a complementary modeling, it is not possible to known the impact the exchanged data may have on the behavior of the receiver.

Directory

A directory is a resource having other resources as children, to handle a tree of resources. The relation directory/child is strong. Deleting the directory deletes the children.

DisplayableLink [presentation of concept]

A displayable link is responsible for modeling an access path, which is associated to a couple of objects in a View. This pair is the first end and the second end of the access path. The 'See Why' text is based on the displayable links of the view. A displayable link is the result Access Road provides to simulate the rights and the relations it finds into a view. The first end of the path is a right user or a privilege source, and the second end is an access target or a group member. For a couple of objects in a view, it may exist none or several displayable links. An access path may be simple, that is with only its first and second ends, or it may be indirect whether it includes some intermediate nodes. The displayable link integrates one access control link for each couple of linked nodes. The displayable link may handle an AG context for each of its nodes.


E

Eligible Party

The main entity for which an access control system delivers access rights or denies accesses to Resource. Actor, UserID and GroupID are kinds of eligible parties. They are all access right users and access sources. There are other access sources that are not eligible parties, as the virtuel folders. The eligible party belongs to an ACS. Another ACS may deliver access rights to an eligible party, which is then considered as an external eligible party.

EndPoint

(new in 0.7.3) A communication end point (CEP) into an ACS may have a network address and two 'black'/'white' lists of senders. A CEP may be an Exchange Point or a Context Switch. The network address may be the full name of an ACSObject or a node in an IP information system. If the network address is an ACSObject name, there is no other actions at the setting. If the network address is a name starting with 'IPv4' or 'IPv6', it is an IP node in the standard IPV4_ADDRESSES_SPACE or IPV6_ADDRESSES_SPACE information system. The name may end with a port number, after the IP address. The CEP 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 nodes of an NameISTree. In this latter case, the items of the lists are the network addresses of the effective senders. Then, they are the CEP having these network addresses. To control the use of a data exchange point, it is possible to set into the senders lists the name of its master program, the name of this DEP, or the name of the network address of this DEP. To control the use of an entry context switch, it is possible to set into the senders lists, the name of this CSW or the name of its network address. On the other hand, the hard or soft alias of an ACSObject cannot be used into the senders lists, both for controlling a master program, a data exchange point or a context switch.

Exchange Point

(new in 0.7.3) A kind of Actor which is an EndPoint for modeling the data exchange point (DEP) of an ACS, or of a program into an ACS, and for modeling an ACS referral. The ExchangePoint properties are displayed by the beamer in the tab 'As Exchange'. A data exchange point is always associated to a unique Actor, named its master program. The master program cannot be an ExchangePoint or a ContextSwitch. An Actor may be the master program of several ExchangePoints. An ExchangePoint may communicate only with its master program, an ExchangePoint or a ContextSwitch.

A DEP models a communication socket or a pipe for its the master program. In this context, sockets are modeled as 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. Each connection between two data exchange points are specific to the ACS, if it is local, or the connection is handled by a network subACS (for instance as IP connections). There are 2 data exchange link types: (1) 'data exchange' rights of the access source, typically when the socket of a client (the DEP) has a Bridge exchange to the socket (another DEP) of a server, to allow readings in data from the server, and (2) 'reverse exchange' rights of an access target on the source, when for instance the AG rights of a Linux program on a Linux domain socket, as DEP and access target, contain a reverse exchange to the socket, to allow writings in the server data from the socket. This is the unique reverse-oriented link type.

The access path (ExchangePoint 1/ExchangePoint 2/ExchangePoint 3) is used to simulate the true path (ExchangePoint 1/master program 1/ExchangePoint 1/ExchangePoint 2/ master program 2/ExchangePoint 2/ExchangePoint 3/). This simplification is possible because the data exchange point is the model of both the socket and the program behavior for any data exchange from and through its socket. This is called the double nature of a data exchange point.

An ACS referral is an optional feature of a data exchange point. It is defined as handling one link to an external ACS that models the DEP master program. It controls the existence and the properties of this external link. Data exchange points and context switches help to model the inner exchanges between the programs into an ACS, and also between the ACS, to simulate the integration of the access controls.

As a context switch, a data exchange point is able to set an access control on the names of the senders, by the way of white and black lists. As a special Actor, a data exchange point is limited, both as source and as target, on its AclEntry, bridge and linked privileges rights. See also the proxy feature of an Actor about the reduced maximal rights of a DEP, which may produce <final reduced rights>.


F

<final reduced rights>

This is a Global or Data Exchange view comment to say, for a given access path, that the global reduced rights have been processed. This is generally the result of the rights restrictions from an exchange point having reduced maximal rights. See also Non-equivalent reduced rights.

<first rate path>

This is a Global comment to say, for a simple access path, that all the indirect paths are forbidden between the two ends of the access path. A first-rate path is displayed with a double width in the view diagram. See also the comment 'no indirect path through'.

fulctr (acronym in a view diagram)

This is the acronym of the metaright 'full_control'. It allows to do all the direct and possible operations on the rights target. It does not deliver administrative rights, that is the rights to change the rights of any user of the target.

Full view

A full view is an user selection of ACS components, called the view nodes, for which Access Road searches the access paths between each pair of components. The nodes may be from different ACS. A full view may contain from 0 to 48 nodes. The access paths may be simple or may include intermediate nodes. They are displayed in a view diagram. A view 'See why' text may also be shown. Any property change among the view nodes or the intermediate nodes is able to update the access paths of a view. The diagram and the 'See why' text are then changed by Access Road.


G

<grant all to second>

This is displayed by a view when the rights owner may delegate to a second owner all the rights he gets, including his administrative rights like this one. This is implemented by the generic right '|transfer_all_rights|'.

<grant to second>

This is displayed by a view when the rights owner may delegate to a second owner all the non-administrative rights he gets, excluding his administrative rights like this one This is implemented by the generic right '|transfer_limited_rights|'.

GroupID and group member

A kind of EligibleParty that contains a set of members. GroupID and UserID are also called group members. A GroupID is sometimes presented as an 'Accounts Group' in the beamer. An ACS may manage a tree of GroupIDs, like the MySQL ® ACS addon.


H

Hard aliasing

This is a main ACS structure property to set that an ACS object may be the hard alias of another one, named the alias reference, from the same ACS. The hard alias has generally no proper rights as access source, since this is the responsibility of the alias reference. The views use the term alias of to show such a relation.

<has target right>

This is displayed by a view when the right user gets all the non-administrative rights of the target, in its proper context of execution as an Actor. This is implemented by the generic right '|get_target_rights|'.


I

Information System [presentation of concept]

The Information System (IS) is a tree structure to handle the varied relations between the ACS. Access Road handles an undetermined number of information systems. Each IS may be viewed as an independent space from the access point of view. An information system is created, opened, saved, closed and removed with the ACS it contains as nodes in its tree structure. It is not possible to create an IS without ACS, but it may contain some passive nodes, as physical or logical components. An ACS may have a subACS which is managed as a separated set of components and rights, and such a subACS is a child of the ACS node in the IS tree. Among the relations from an ACS to another, there is the tied relation forcing an ACS to be open with its ACS parent. Other relations are visible in the IS window, but they are unused in Access Road 0.7.x.

<inherited XXX>

This is a view comment to say that there are inherited rights, for a given Link. They are delivered by the direct parent and/or the indirect parents of the target. Access Control List rights, Account/Group rights and Linked Privileges may have an inherited form if the ACS manages it. This is also possible for specific ACS addon rights, like the Ubuntu 'AGO Other rights'.

Init contxt (initial context) or 'Run Under'

In a view, when there is an access path to an Actor starting under a given UserID or GroupID context, this actor runs under this UserID or GroupID, as component of the proper AG context of the Actor. A relation 'Run under' is created in the view from the Actor to the relevant UserID or GroupID. This relation is displayed in the view diagram as a line with the comment 'init contxt' (for 'initial context'). 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 adddon Actors, like ExecutableUbuntu in the ACS addon Ubuntu, or the DEFINER mode in the ACS addon MySQL.

Note: the relation 'Run under' is also to be compared to the relation 'recv contxt'/'May Run Under'.

Note 2: when an Actor is executed, the switching of the received AG context to the default one is tagged in the 'See why' text by <sets Owner> and <sets Group>. This rule is also recommended to the ACS addons.


L

Link (or access control link)

A link in a view is responsible for defining the set of link types that is applicable between near two base objects (for instance CONTAIN or ACL), including the rights between them. Access control links are used in the displayable links of a view. See also 'Link type' and 'Rights'.

Link type

There are several link types, and the main ones are presented in this glossary, like ACL, CONTAIN, OWNER, BRIDGE, or virtual member of a virtual folder, linked privilege and alias. Some types have negative versions when the rights are negative.

Linked privilege

To create a linked privilege, let's see in the beamer the ACS tab 'Rights 2'. The linked privilege manages some immutable access rights (it is a positive privilege) or some access restrictions (it is then a negative privilege) from a set of eligible parties, as sources, to a set of resources or virtual folders, as targets. A linked privilege is created and deleted from its ACS. It handles 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. A linked privilege may inherited from the Resource or VirtualFolder parent. There are four types of linked privileges: simple, if-all-sources, internal one-to-one privilege and external one-to-one privilege. A linked privilege contains one or more immutable rights which follow the rights list managed by the relevant ACS which manages this privilege. If the concept of linked privilege is applicable, an access control may be simulated by Access Road by the mean of such an object, even if 'privilege' is not the term used in the software documentation. The linked privileges and the typed privileges are totally independent. Note: the versions 0.7.x of Access Road fully implement the simple linked privileges into the generic access path search. The other kinds of linked privilege are not handled.


M

<may grant all to third>

This is displayed by a view when the rights owner may give to or remove from a second owner the right to give to or remove from a third owner all the delegated rights the second owner has received, including the administrative rights like this one. This is implemented by the generic right '|transfer_all_rights_to_third_party|'.

<may grant to third>

This is displayed by a view when the rights owner may give to or remove from a second owner the right to give to or remove from a third owner all the delegated non-administrative rights the second owner has received, excluding the administrative rights like this one. This is implemented by the generic right '|transfer_limited_rights_to_third_party|'.

Member

Acronym used in a view diagram to indicate a Contain link.

<modify from parent ACS>

This is displayed by a view when the right user may perform updatings on the target state from the parent ACS. This is implemented by the generic right '|modify_from_parent_acs|'.

<modify owner>

This is displayed by a view when the right user may may change the target owner in its ACS. This is implemented by the generic right '|modify_owner|'.

<modify right>

This is displayed by a view when the right user may modify all the right descriptors, but not the owner nor the super-administrator. This is implemented by the generic right '|modify_security_descriptor|'.


N

Name

The name of an Access Road object always starts with its information system name, then its access control system name, followed by some other components if necessary. Two successive components in the name are separated by ':: ' in the textual representation of the name. When it is a Resource, the name contains all the hierarchical path of the resource in the resources tree. When it is an UserID (or a 'GroupID'), the first name component after the ACS name is '<U>' ('<G>' respectivelly). When it is a NoMore-NoLess view, the component before the last one in the name is '_NMNL_'.

Node

A node is a container of leaves or others nodes in a hierarchical tree. Directory and VirtualFolder are nodes.

No-Less-Than Right

In a NoMore-NoLess view, the No-Less-Than right is the property to compare for stating if the less criterion is fulfilled or not. A NoMore-NoLess view may not have No-Less-Than right. In the view checking perimeter, if there is at least one right user which have all its rights lesser than the No-Less-Than right on the view access target, then the less criterion is not fulfilled in this view, and then, the No-Less-Than right is displayed in red. Otherwise, it is displayed in green.

No-More-Than Right

In a NoMore-NoLess view, the No-More-Than right is the property to compare for stating if the more criterion is fulfilled or not. A NoMore-NoLess view may not have No-More-Than right. In the view checking perimeter, if there is at least one right user which have at least one right greater than the No-More-Than right on the view access target. The more criterion is not fulfilled in this view, and the No-More-Than right is displayed in red. Otherwise, it is displayed in green.

<non-equivalent reduced rights>

For the ALIAS types, that is including the soft aliasing and the hard aliasing, this is a comment to say that the rights are reduced because the target ACS has not a right equivalent to at least one right of the outing ACS, in a given access path. A less powerful right is selected. There is a kind of rights loss along this access path. See also <final reduced rights>.


O

OWNER link type (acronym in a view diagram: [own])

This is a structural access control link type, which defines the relation between an UserID and one of its resource.


P

Parent ACS

The parent ACS is the ACS on which the current ACS runs software. The parent ACS is the parent node in the information system.

PATH in a view

See DisplayableLink.

Privilege

See the typed privilege and the linked privilege.

PRI inheritance

This is a main ACS structure property to set the linked privileges are inherited in the resources or the virtual folder tree. Among the types of linked privilege, the if-all-sources privilege is the single type which cannot be inherited. Only one target is authorized to the linked privilege if the first target is from an ACS that manages the PRI inheritance. The inherited one-to-one linked privilege may be external. The typed privileges are never implied in the privilege inheritance.

<PROC>

This is displayed by a view to indicate a processed right. For instance, the MySQL addon sets a workable AclEntry from two to-be-mixed AclEntries, for an account and for an accounts-for-hosts group. The resulting AclEntry is not in the base but appears in the view as processed right with the acronym '<PROC>'.

Policy checksum

(new in 0.7.1) Access Road sets the ACS policy checksum and adds it to the ACS type. The policy checksum is immutable after the creation of the ACS. It is producted from the property values into the beamer ACS tabs 'Structure' and 'Structure 3', 'Types', 'Rights' and 'Actions'. Caution: if the ACS designer sets then unsets a policy property value, this action may modify the policy checksum, even if the state of the ACS to create is unchanged.

Proxy feature of an Actor [presentation of concept]

This section explains the two concepts of right-proxy Actor and reduced maximal rights for an Exchange Point (new in 0.7.3), which is a kind of Actor. The property 'Is a Right Proxy' is displayed in the beamer tab 'As Actor'. An Actor is a right proxy by default, when it is an intermediate node into some access paths. The effective rights in the real world for which this Actor is a proxy are unknown. They may be stable, or they may depend on the current interaction with the caller. It may appear that a given program is a full right-proxy, e.g. it trully never limits the rights of the previous nodes in the access path. This case is not explicitly considered in the generic Access Road model. The approach is to rather simulate the worse cases. The default state is to have a right proxy for some unknown rights.

The only mean to improve the knowledge about an Actor would be to model it as a separate ACS. For instance, the MySQL Server runs under Linux as the deamon 'mysqld', that is modeled as a right-proxy Actor with an ExchangePoint (to simulate its network socket) for calling the 'MySQL server' ACS. Then, the internal behavior of the Actor 'mysqld' as right proxy is fully simulated by the 'MySQL server' ACS. Otherwise, without such dedicated ACS, there are two alternatives, as we will see hereinafter.

(1) The first choice for the Access Road user should be to keep the default value, that is 'true', to tell the Actor is a proxy for some unknown rights, and not a proxy for the other ones. This selection of rights by the Actor may be static or dynamic, following some unknown algorithms. In the 'See Why' text of the views, when such an Actor is an intermediate node in an access path, a comment reminds this Actor should reduce some of the rights, for the first end of the path.

There is then a specific issue for the Less criterion of a NoMore-NoLess view. This criterion may be considered as fulfilled, while this is false if a right-proxy Actor provides some unknown limitations of rights.

(2) The second choice for the Access Road user should be to set the is-right-proxy value to 'false', if they are proven arguments about the behavior of the Actor. This is an important presumption. An error at this level may break the consistency of a whole design. The no-right-proxy Actors are listed into the ACS properties and into the 'See Why' text of the views. Furthermore (new in 0.7.3), such an Actor is displayed in a view diagram with a special cross, to recall its state. When there is a no-right-proxy Actor N into a view with paths from a node A to N and paths from N to a node B, a comment '<No indirect path through> N name' is added to the simple path from A to B. This helps to avoid any misunderstanding of the 'See why' text about the abilities of the no-right-proxy Actor N.

Here is a presentation of the second concept: the reduced maximal rights for ExchangePoint. An Exchange Point is a kind of Actor limiting the maximal rights of the master program for which it communicates. The maximal rights are implemented as 2 lists which are displayed in the beamer tab 'As Exchange' of an Actor. Here is an exemple of use. The MySQL client socket is an ExchangePoint on a desktop. It communicates with the MySQL Server socket (another ExchangePoint) on the server, by the way of a network. Reading and writing the MySQL data are well-known abilities of the MySQL client. These readings and writings are not explicitly managed as rights, neither from the point of view of the two programs, nor for the operating systems of the desktop or the server. They may be viewed as operational features of the MySQL client and server, rather than managed rights. On the other hand, Access Road has to handle these features as rights in the access paths, to explain how a desktop user may read/write a MySQL data on the server, or how it may execute a MySQL procedure on the server, all this through an access path containing simply an IP socket connection. As a reverse example, the client socket would be the client of a supervision tool having only a feature for collecting MySQL data, without any ability to change the MySQL data. Then, 'read' would be the maximal operational right on the MySQL Server socket for the ExchangePoint that simulates the socket of this supervision client. All the executing (on procedures) and writing MySQL inner rights would have to be rejected for that client, and this is an ExchangePoint feature. On the other hand, into an Access Road simulation, the MySQL client has to be able to fully act on the MySQL server. Its maximal operational right would be the metaright 'full_control'.

The master program of an ExchangePoint is also an Actor. For the ExchangePoint of an Actor master program, the reduced maximal rights may be defined for the source which sends a call to this ExchangePoint, and/or for the target which receives a call from this ExchangePoint. The default state is to have no reduced maximal rights, and the maximal right is the metaright 'full_control'. Generally speaking, for both the Actors and the ExchangePoints, the default state implement the fact there is no confidence in the code of the program which is modeled (or, for a socket, the operating system code that handles the socket). Even if the functions of a program does not include a given operation - say, write a data - the program may contain a secret malicious code doing this action. It is rare to be able to prove that there is no security failure in a software code, nor through the input data. However, there is the case where the Actor explicitly includes an access control function, to filter the types of operation through it. A more common case is when the modeled program is so well-known that the Access Road user thinks this Actor is trully able to deny a given right to its caller (like the exemple of a well-known supervision client which never writes MySQL data). Then, the user may take the responsability to model this feature of the Actor. He defines some reduced maximal rights on the Actor ExchangePoint.


R

<read from parent ACS>

This is displayed by a view to indicate a global reading ability from the parent ACS. This is implemented by the generic right '|read_from_parent_acs|'.

Recv contxt (received context) or 'May Run Under'

In a view, when there is an access path to an Actor which is executed from a given UserID or GroupID context, this actor may run under this UserID or a GroupID, as component of its AG context. A relation 'May Run under' is created in the view from the actor to the relevant UserID or GroupID, if it is in the view, and if there is at least one matched access path to the actor. It is displayed in the view diagram as an arrow with the comment 'recv contxt'. The term 'May' is used because the Actor may be accessed from other AG contexts. This feature depends on the current nodes of the view, from which the access paths are found. It may be compared to the relation 'init contxt'/'Run Under'. Caution: if there is 'May Run under' from the node A to U in the view, when a node G is added to the view, this relation disappears if all the paths from U to A have to pass through G.

<reduced rights for data exchange>

For the two Data Exchange and Reverse Data Exchange types, this is a view comment to say, for a given Link, that the ExchangePoint restricts the effective rights of the source to the target, if it is a Data Exchange, and for the target to the access source in the inverse case (See the proxy feature of an Actor about the reduced maximal rights). This comment is added to an intermediate relation into an access path. The resulting rights for the path are defined in the last relation. The comment <final reduced rights> is added in the last relation of the access path.

Resource

An entity which is an access target in an access control system. It belongs to one access control system which controls it. Directories, Actors, Executables are kinds of resource. Following the ACS structure and policy, a resource may manage its own access control lists, may be owned by an userID, and may be member of one or several groupIDs. Through the access control lists of other ACSs, the resource may be an external controlled resource. Most of the time, an ACS manages a tree of resources.

Restored User/Groups

When a displayable link describes a 'loop' accross a second ACS 'B' - that is, coming from a first ACS 'A' and returning to this ACS 'A' - then, where the path leaves 'B' to return to 'A', there may be a switch between the 'B' Account/Groups context and the elements get from the ACS 'A' before the entering of the displayable link into 'B'. By this way, these elements are restored as the new applicable Account/Groups context in the ACS 'A', after the path loop into the ACS 'B'. The comment 'Restored User/Groups :' is then added to the link at the border of the ACS 'B' to 'A', with the nick names of all the applicable User and Groups coming from the ACS 'A'.

Reverse Data Exchange

This is an access control link type, which defines the relation between 2 processes which may exchange some data. An example is between the server using an IP network socket for its network communications, and this network socket. Unlike the data exchange type, the rights are applied to the inverse sens, that is the rights of the access target (the socket) on the access source (the program). These rights may be constrained by the proxy feature of an Actor, for the reduced maximal rights of a data exchange point.

Rights

See StringRight.

Right-proxy actor

By default, a generic Actor is a right proxy, so it participates to the access paths as intermediate node when it may be executed, that is, more generally, when it may have the behavior of an active object having access to other components. Saying an Actor is NOT a right proxy means it is not transparent for the right users which execute it. Running it may bring new specific rights coming from the inner rights of the Actor, from its properties and its proper execution environment, but this is not mandatory. Without such inner rights, the no-right-proxy Actor is never an intermediate node in a path, while it may be an access source or an access target. The effective rights for which a right-proxy Actor is transparent are generally unknown. To go further, let's see the Proxy feature of an Actor.

Right user

A right user is an entity which has the capacity to access to an access target, if the ACS allows it. Eligible Party is an ACS entity which is a right user, and Virtual Folder too. An ACS may be a right user by its ability to access to other ACS.

Root (static and dynamic root, root actions)

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 exemple 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 '' 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.


S

Secondary actor group

See Actor.

<sets Group>

See Init Contxt.

<sets Owner>

See Init Contxt.

<Should limit rights>

For the right-proxy Actors, this is a comment in the 'See Why' text of a view, to say that these programs should reduce the effective rights on the target that Access Road finds. Although such a program is a right proxy, it may have a complex behavior about the rights it delivers to the rights user which executes it. Since this is not modeled by Access Road, it is not possible to be more precise (new in 0.7.3).

Sketcher in the GUI

The Sketcher window provides the simplest view in Access Road. It shows the simplest direct links and rights around a selected object in the explorer. For example, the relations from a ContextSwitch are never detected by the sketcher, because they depend on the previous nodes 2 steps before. CAUTION: if a relevant property is updated and if then, the links or the rights are changing, the Sketcher view is NOT updated.

Soft aliasing

This is a main ACS structure property to set an ACS object may be the soft alias of another one, named the alias reference, from the same ACS or not. The soft alias has generally no knowledge of its reference, while the contrary is not true. The views use the term alias of to name such a relation.

StringRight [presentation of concept]

A StringRight is an ability to do an action on an ACS object. In a view diagram, each right has an acronym if the inner right name is too long. A positive right allows the action, and a negative right forbids it. Most of the rights are set and managed by one ACS . They are called ACS rights. The ACS rights are defined at the creation of the ACS. There are also generic rights which are not related to an ACS. Each right - ACS or generic right - is defined in a network of upper and lower rights. The upper right is a greater right, in other words, it delivers or restrains more power to the right user. The network of the generic rights defines the set of all the possible rights into all the information systems. A generic right may be a managing right which defines an action upon the rights or a general tag, like '|unverified_rights|'. there are 11 generic managing rights. Their names are always framed by '|'. The managing right '|unknown_rights|' is the less powerful right, with a strenght at 1. '|is_superadmin|' is the more powerful right, with a strenght at 90900. The strenghts are the main property to compare the rights for the criteria of a NoMore-NoLess view. The generic managing rights are into a dedicated network, without connection with the other non-managing generic rights. Each ACS right has a generic right which defines its true meaning and power. Then, it becomes possible to compare the ACS rights of different ACS through the comparison of their generic rights. It is possible to add rights to summarize them in an upper right. For instance, in Linux Ubuntu ®, the sum of the file rights 'r', 'w' and 'x' is the right 'full_control'. The inverse operation is to subtract a right from another right. In Linux Ubuntu, 'x' subtracted from 'full_control' gives the rights 'r' and 'w'. Then, if the ACS uses the rights subtraction, each right has an opposite right. See also Conditional Rights.

Structural link types

The main structural link types, as displayed in a view, are own for an UserID (OWNER), member of a GroupID (CONTAIN), indirect member of a GroupID through a chain of several CONTAIN links, alias of a hard or soft alias, and Run Under an UserID or a GroupID. A view diagram displays the structural links in blue, while the other links are in black.

Structure of an ACS

The structure of an ACS is a set of 22 properties defining the main features a given ACS manages, like the handling of Account/Group rights or Virtual Folders. The structure of the ACS is displayed in the beamer into dedicated tabbed panes named 'Structure' for the 22 mandatory properties, and if it is necessary, the panes 'Structure 2', 'Structure 3' and 'Structure 4'. The 22 ACS main properties are presented in this glossary.

SubACS [presentation of concept]

A subACS is an internal component of an ACS that is displayed apart in the explorer and in the information system tree. A subACS may be defined for the Resources, for the GroupIDs, or both. A subACS has generally a specific ACS policy for the types and the rights of its components. The Linux Ubuntu® ACS addon is an exemple where the subACS 'authorization' is both for Resources and GroupIDs, and the subACS 'capability' is only for GroupIDs. They are subACS because they model two distinct sub-systems into a Linux® operating system.

<superadmin>

This is displayed by a view when the right user, as super-administrator, may perform all the possible operations on the target. This is implemented by the generic right '|is_superadmin|'.




T

Transfers/converts rights

This is a view comment to say that the received rights of the relation are transfered to the next relation into the access path. Between two ACS, the rights may be converted to compatible rights from the second ACS.

Type of an ACS object

A resource or an eligible party is created with a type, among a list of allowed values set by the ACS policy. This type is then ridden by the ACS to allow or forbid each operation on this object, and to set the range of values for each object property. For instance, the rights a resource may have in one of its ACL, may depend on both the ACL ACS, the resource type, and the eligible party type. This is the case in a RBAC application ACS (see the 'constrained specialized rights' in the tab 'rights' in the beamer). An important part of the design for a new ACS is to set the types handling in the ACS policy. Use of '<immutable>': The type may start with '<immutable>', and this means that Access Road forbids any change on the object properties. It is then usually possible for the user to change the type, to get the right to change a property (for instance, from the type '<immutable> directory' to 'directory'), and after that, the user may reset the type to its immutable version. Use of '<created-by-AccessRoad>': this start in a type signals an object that Access Road has created, for which no change and no deleting are allowed to the user.

Typed privilege

To create a typed privilege, let's see in the beamer the ACS tab 'Rights 2'. The typed privilege manages some immutable access rights (it is a positive privilege) or some access restrictions (it is then a negative privilege) from a set of eligible parties or resources, as sources, to a set of resources or virtual folders, as targets. A source has rights upon a 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. One typed privilege is then designed to produce rights for numerous sources and numerous targets, but without ability to change them except from a straight deletion of the typed privilege. A typed privilege is created and deleted from its ACS. It handles immutable references to its sources and targets, and the rights cannot be changed after the creation. This is not the behavior of an AclEntry or a linked privilege. As a generic feature, a typed privilege cannot be inherited from the Resource or VirtualFolder parent. There are four types of typed privileges: simple, classed, specific and for an authorization server. A typed privilege contains one or more immutable rights which follow the rights list managed by the relevant ACS which manages this privilege. A typed privilege is registered by the program in the relevant sources and targets. They may be external ones (that is, their ACS is not the Privilege ACS) only for the authorization servers, and then the privilege is not registered in its sources and targets. If the concept of typed privilege is applicable, an access control may be simulated by Access Road by the mean of such an object, even if 'privilege' is not the term used in the software documentation. The linked privileges and the typed privileges are totally independent. Caution: the version 0.7 of Access Road implements fully only the simple typed privileges into the generic access path search.


U

<Unkown>

This is displayed by a view when the rights are unknown. This excludes the cases where the rights are known to be null. This acronym is used rarely, only when a complex situation occurs beyond the modeling capacities of Access Road. This is implemented by the generic right '|unknown_rights|'.

<unverified right>

This is displayed by a view when the declared rights are unverified by a certification authority; this is a metadata added to the declared rights. This is implemented by the generic right '|unverified_rights|'. It is worth reminding ourselves that the right should be overestimated or underestimated by the Access Road user or developer, for instance if the program contains a malware.

<Used in indirect paths>

This is a GLOBAL comment to say, for a given access path, that some extensions of this path are used to define some 'no indirect path through' comments in the access paths of the same view. The view diagram draws a special icon at the center of an access path having this comment.

UserID

This is an account in an Access Control System, as a kind of eligible party. Typically, each human user has a personal userID for logging in the operating system. Programs on a server have generally one or several dedicated accounts to run varied executables in the operating system.


V

<via> and <via: should limit rights>

The <via> tag is displayed in a view diagram. The following rights are those get through some intermediate nodes into one or several displayable links. When the intermediate node in a displayable link is an alias, this tag is not used. It is useful to detect in one look the presence of intermediate nodes, because they should reduced some rights. Because their behavior is not further modeled by Access Road, it is not possible to be more precise. The tag <via: should limit rights> is set in the the 'See why' text of a view. Into an access path, when an intermediate node is a right-proxy Actor, this comment is added to tell: 'These programs may restrict the effective rights of the initial right user on the target, but the model does not know on what scale.'.

View

This is a set of base objects, selected by the user, on which the searching of access paths is automatically processed by Access Road. It is associated to a diagram and to a text. The full view displays all the rights and relations, if any, between each couple of base objects in the view, by the mean of displayable links. The NoMore-NoLess view displays if a set of right users have their rights on a given access target, which fulfill or not the two more and less criteria.

Virtual Folder

To create a virtual folder, let's go to the ACS beamer tab 'Right Users'. A virtual folder is a folder of resources belonging to one ACS, responsible for being a privilege target, an alias or an alias reference. A virtual folder is also a right user since it manages a 'virtual member' type link to its members. The relation virtual folder/member is weak. On the contrary of a directory, deleting the container does not delete the members. There are two main types of virtual folders, where the members are always Resources, (1) for resource members which are not eligible parties and (2) for resource members which may be eligible parties. Thus, a virtual folder is an access target, and it is an access source only as reference of an alias or as container of its members. The default behavior in the rights propagation is the virtual folder transfers none of its rights, as target, to its members. An another ACS mode is possible, where the inverse rule is applied. Tree of virtual folders is a structural property of an ACS. There is no privilege rights inheritance in such a tree, but an ACS addon may change this behavior.


A B C D E F G H I L M N O P R S T U V

®All trademarks are property of their respective holders.
Copyright 2000-2013 ACCBEE - All Rights Reserved.
Last modification : 11 February 2013