Access Road Technical Paper
Examples of access control design
with diagrams (2)
Previous | Next
Access Road Documentation
| Generic access control
system model
Contents of this paper:
- Introduction
- Useful security design
patterns
- Web server use
- Access control policy
for the web server
- Access control main
solution
- Try out a static representation
of access control on the web server
- Try out a dynamic representation
of access control on the web server
- Diagrams usefulness
in access control design
- Alternatives for
access control on the web server
Try out a static representation of access
control on the web server
An access control system is defined as to be responsible for
access decisions. A resource belongs to an account, and sometimes
to a group (on Linux). The resource is then drawn in the ellipse
of the account. A running process is associated to an account.
Access rights and access denials link ressources (the targets
of the accesses) to potential eligible parties (the users of access
rights) such as an account, a user group, an executable, a server,
an user, or any activ entity in the information system. Shown
in a static diagram, the access control design of these objects
is more easily undertood and memorized, for example for system
administration.
First, this is a static access control diagram for the Linux
part of the web server:
The Apache-related access control functions are listed (to
read more, see Apache site on links page):
- Apache
1.3, in the standalone mode, runs several copies of itself to
handle multiple connections simultaneously coming from the web
server authorized ports. 80 is the standard port for HTTP, and
partner's firewalls shouldn't appreciate a change of this. But
only the Linux superuser can attach a process to this port, so
the Apache server must at least start up under the root account.
The Apache solution is to create, when it starts, copies of itself
(Apache children) running under a safer account (webuser here).
Only the original process (Apache parent) retains the root account,
and it never handles the network (pattern read protection
of a process internal data by a setUID-like function).
- Server-side
includes option is turned off in the Apache configuration. The
configuration file for Apache access control is .htaccess in
the root directory. The Allow and Deny directives are used to
restrict access only from and to the partners IP addresses.
- The
SSL module allows to restrict HTTP and FTP directories only to
partners who present X-509 certificates registered by the web
server, that acts as a certification authority. Every Apache
client must present a valid certificate, and its on-line version
gives the Apache account name to be used during the SSL connection
(option SSLFakeBasicAuth): Ap_partner_i for the partner i.
- In
the Apache configuration, the Apache account Ap_partner_i has
an associated Linux directory partner_i that belongs to the Linux
account Li_partner_i. Ap_partner_i may run only scripts in the
directory cgi-bin/partner_i.
- suEXEC is an Apache module
which provides assurance about the security of CGI scripts. After
several security controls and having cleaned up the Linux process
environment, suEXEC runs the script under the Linux account of
the script's owner, in the script's own directory. All scripts
in the directory cgi-bin/partner_i belong to the Linux account
Li_partner_i.
Here is the static access control diagram for the Apache part
of the web server:
Notice that such representation
deals with complex access control issues. For training or communication
purpose, it needs to be explained. It may help the access control
designer to recall his proper work three months later. By the
way, it is just a first try in the search of graphical standards
for access control design (to see more, read the analysis documents
of the Access Road project).
Try out a dynamic
representation of access control on the web server
Static diagram does not represent the streams between running
processes. There are quite difficult to link to the actual behavior
of the system. This first dynamic diagram is an access control
collaboration diagram. It is an equivalent of the UML
collaboration diagram about the send of a file from the partner_i
server to the enterprise application server. The same processes
are shown in the two diagrams, with some precisions here on their
running access control contexts:
With access control collaboration diagram, it is possible to see
the interactions between processes, but not the data streams.
It is completed by the access control data diagram, which reuses
the numbers in the previous diagram to link the data streams to
the process calls. The convention here is that the data strams
are always at the end of the process call.
Previous
| Next
Access Road Documentation
| Generic access control
system model
Contents of this paper:
- Introduction
- Useful security design
patterns
- Web server use
- Access control policy
for the web server
- Access control main
solution
- Try out a static representation
of access control on the web server
- Try out a dynamic representation
of access control on the web server
- Diagrams usefulness
in access control design
- Alternatives for
access control on the web server
______________________________________________________________________________________________________________
All registered names are trademarks of their respective
owners.
Last modification : July 25, 2001
© Copyright 2000-2001 TPA Conseil - All Rights Reserved.