Access Road Technical Paper

Examples of access control design with diagrams

© Copyright 2000-2001 TPA Conseil
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 "The Access Road project", with the Front-Cover Text being "The Access Road project", and with no Back-Cover Texts. This license is applicable for 20 years since the publication of the documentation. The applicable laws are the French ones, and the relevant court is at Nanterre (92), FRANCE, EU.
A copy of the license is included in the section entitled "GNU Free Documentation License".

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

Introduction

This technical paper has several purposes:

• take the example of a realistic modern information system to figure out the diversity and the complexity of access control functions in current platforms.
• show how security against external and internal intrusions has not only to deal with firewalls, cryptography, intrusion detection systems or generic operating system hardening, but also with design of a specific and comprehensive information system.
• show how access control design needs skills both in architecture, technical security and method, all together.
• prepare the analysis phase of the Access Road project, where the visual representation of access controls has to be chosen.
• explore in an balancing way the design alternatives, and justify the technical choices in the light of aspects like user organization, security policy, product functions and administration constraints.
• show the usefulness of diagrams in access control design.

Note : Bear in mind that this description in not a definitive reference for configuring access controls in any system, but is intended to demonstrate highlights of how an information system is designed as a whole. In your system, another design choices should be better.

In the first version of this paper, only the access control issues of a corporate web server are analyzed. The use of the Access Road software is not considered in this technical paper.

Useful security design patterns

Architectural pattern:

• defense in depth: no protection is perfect. Secure systems must be built up with several concentric high defensive walls, with the upper values located in the center of the structure. For instance, for higher levels, it is not safe to set the security only in the application or only in the firewall.

Methodical pattern:

• access policy: set who (user, process) is authorized to access to what (resource like server, directory, process, user...) and how (for running, reading,...), and who is not authorized to access to what.

Technical security patterns:

• read protection of a process internal data. The issue is : how an user may be able to run an executable, but without any capacity to read the executable internal data ?
  • by an independant thread: the executable is run as an independant thread at the start of the computer session, and the user's programs exchange with it through the operating system communication system.
  • by the application: in an executable, an inner logic allows to log in another account on the local system; this is the only account authorized to read the sensible internal data (keys for example). So, the executable, when it is run by any account, can read the internal data but the account caller can't. If a password is used for the logging, it is hard coded in the executable.
  • by a setUID-like function: the executable runs under a dedicated account that it is not the user account who runs it. On Linux/Unix, the executable is a SetUID or SetGID program. On Windows NT/2000, it is a service. The executable account is the only one to have the capacity to read the executable internal data.
  • by remote logging: like 'by the application' pattern, but with a remote connection to an another computer.
  • by explorer restriction: the user and the executables that he runs can't use any explorer-like tool for reading the directories, and can't install any software. User runs executables only through dedicated menus. Configuration files are used by the executables for getting the file paths.

Web server use

The Linux/Apache web server of a large enterprise gives to business partners the ability to communicate with the internal information system. It is used to exchange XML documents through FTP links, and to display the current state of file transfers for every partner by the mean of HTTP documents. HTTP and FTP external accesses use the 128 bits SSL protocol. The partners' certificates are manually distributed (no PKI).

The web server is located outside the entreprise sites, at a distant Internet provider. For communication from the entreprise internal system to the partners, an application server under Solaris is used in the main site. The application server runs in three steps:

• copy on the web server the HTTP and XML files to be exported. It uses SCP, a secure file transfer protocol.
• log on the web server with SSH, a secure shell.
• then activate on the web server the FTP transfers on Internet to the site partners.

The exchanges from the Web server to the entreprise application server use FTP and CGI scripts invoked by the partner on the Web server. XML files are transferred from the partner to the web server with FTP. A CGI script in Perl downloads the incoming XML files to the application server with SCP.

The communication through SSH and SCP is by the mean of two free-software openSSH servers on Solaris and Linux servers. It is authenticated through 1024 bits RSA keys, signed and encrypted with 128 bits IDEA keys.

This UML collaboration diagram describes the implied components in the transfert of a XML file from the enterprise application server to the partner server:

This UML collaboration diagram describes the implied components in the transfert of a XML file from the partner_i server to the enterprise application server:

Access control policy for the web server

• nobody and no process has direct or indirect access to the entreprise internal servers from Internet, excepted through the authorized path (call of a dedicated script on the web server, for file transfers only).
• nobody and no process has access to Internet from the internal information system, excepted through the authorized paths (only file transfers and HTTP communication on Internet, all launched by a dedicated program on the entreprise application server).
• partners have only HTTP and FTP accesses to the web server (through SSL). They can't read or write their dedicated CGI scripts.
• a partner has no access to other partners exchanges through this web server.
• a partner has no access to the Apache kernel resources or to the system resources on the web server.
• a CGI script has no direct access to the internal data of the network programs and deamons that communicate with the entreprise application server.
• only authorized characters are considered in the input streams of every CGI script.

Access control main solution

To isolate the internal information system from Internet, a firewall is built up with two packet filtering routers and a 'bastion host' as Linux/Apache web server.

The external router has the following access functions:

• block packets for all services, except FTP and HTTP.
• block packets that have IP source routing or that have other unusual options set.
• block packets addressed to the internal information system or to the internal router.
• only pass packets for which the source or the destination IP address is that of the web server, and for which the ports are those defined for FTP, SSL and HTTP.

The internal router is from an another provider. It has the following access functions:

• block packets for all services, except SSH and SCP.
• block packets that have IP source routing or that have other unusual options set.
• block packets addressed to the external router or to Internet.
• only pass packets for which the source or the destination IP address is that of the web server, and for which the ports are those defined for SCP and SSH.

This study is also a good opportunity to test the interest of some diagrams. Access control systems deal with ressources (the targets of the accesses) and 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.

Here in a graphical representation of access rights in an access control system (ACS):

Then try out a static representation of access control in the routers:

The web server is based on Linux-Mandrake, Apache and OpenSSH.

The Linux-related access control functions are listed (to read more, see Linux and Mandrake sites on links page):

• the Linux operating system is the Mandrake 7.0 distribution, installed with the higher level of security (level 5 of the Mandrake SECurity tools). At this level, several security controls are set. For instance, verify every minute that every Ethernet card is not set in the 'promiscuous' mode used by a sniffer for listening the packets. All unused services are removed (graphical desktop environment, lp...).
• All network services are removed, excepted HTTP, SSL, FTP, SSH and SCP, only authorized on specific ports (80, 443, 20, 21). All others IP ports are closed. No use of DNS and SMTP.
• the account and group structure is the following:
  • the wheel group, with the root account.
  • all the classical groups and accounts on a Linux server (sys, nobody...).
  • the webgroup group, with the accounts: webuser, docs, scpuser, and the couple (Li_partner_i, transfer_i) for each partner i.
  • the enterprise group, with the application account.
  • the admingroup group, with the admin_i accounts (one account per administrator).
• each directory and file owned by any account may be read/write by the owner, and is forbidden for all accesses from the group or the others, excepting for:
  • every 'partner_i docs' directory that contains the HTML pages dedicated to the partner i, which belongs to the Li_partner_i account and may be read and write (write for FTP only) from its group, which includes webuser (with no read from the others).
  • the common HTML pages of their site are in the common directory which belongs to the docs account and may be read from its group.
  • CGI scripts owned by the transfer_i account, that are stored in a cgi-bin directory with an authorized access by the owner for execution only, and no other authorized access for the group or the others (see suEXEC with Apache).
  • the scp program, owned by scpuser, is set to be authorized to the group (webgroup) for execution only. It is a SUID program (but not a root SUID one!), and it runs under scpuser account. So, each CGI script run by a partner can't read and write confidential scp internal data, since it is forbidden to the group. On the other side, the application server authorizes, through the SCP protocol, only file transfers into a dedicated directory. Of course, the scp configuration file and the associated keys can't be read or write from the others.
  • at the Linux level, the connection of a specific partner is unknown. He is only known by Apache, and is associated by Linux to HTTP/FTP connections and to the account webuser under which Apache runs. Each partner i can, through the Linux group access, read its HTML pages owned by the account partner_i.
• the umask of every account is set following the same principles.

The CGI script access control functions are:

• every CGI script run through HTTP access is protected from input streams; that is, containing malicious characters as those specially interpreted as commands by the Linux shell. Every script includes an access control function, where all input values from Internet are checked to be of appropriate length, and with characters all listed as allowable.

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

______________________________________________________________________________________________________________