Access Road Technical Paper
Examples of access control design
with diagrams (3)
Previous
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
Diagrams usefulness in access control design
All the previous examples show us access control as a result,
after the design process. Let's talk about the usefulness during
the design, when an alternative is identified by the designer.
Suppose that the designer would like to simplify the previous
design. The Linux groups and accounts seems quite complex. Its
question is: is it possible to remove 'transfergroup' and to put
the corresponding accounts in 'webgroup'? Here in the derived
access control data diagram:
It appears that there is a major limitation in this new design:
the scp program, under the 'scpuser' account, has to read the
partner_i XML file to send it to the enterprise application server.
This file is in a directory belonging to the 'transfer_i' account
in the same group 'webgroup'. So, it is necessary to allow the
group to read this directory for the scp access. But the other
'Li_partner_J' accounts are also in this 'webgroup'. From the
Linux point-of-view, they would be able to read the XML file send
by another partner. This access is strictly forbidden in the access
control policy! A protection remains yet, since Apache denies
any access to others 'part_J scripts' directory, following this
diagram:
Then, all seems ok. Can we simplify the design? No, it would
be unsecure! Why? Look at the Apache rights on the 'part_i docs'
directory. Partner i can write through FTP on this directory.
So, he could load here unsecure http files with scripts that he
has written! Such a script, by the mean of suEXEC, would run under
the 'LI_partner_i' account. So, it could read in the 'part_j scripts'
directory of others partners! Of course, solutions do exist if
the design insists to remove 'transfergroup', but they are associated
to other kinds of new complexity, and they implied to put confidence
in Apache rather than Linux.
This little example is not a definitive course about access
control, even for this specific example. Its aim is just to show
the interest of diagrams in the access control design.
Alternatives
for access control on the web server
Alternatives for routers
architecture:
- higher
security:
- use
of network address translation: it is a form of access control
on the IP address. Possible with a proxy as Socks for instance,
that may also do port translation. Port translation would allow
to select for HTTP on the web server, another port than 80 if
the proxy translates the targeted port (80 for HTTP) of the incoming
packets. So, Apache parent process shouldn't run under the root
account on Linux.
- lower
security:
- use
of only one router : forbid unused protocols, but no control
on the streams.
- use of a specialized firewall:
unnecessary complexity, so less secure here, I guess.
Alternatives for web server
operating system:
- higher
security:
- use
of OpenBSD instead of Linux: it is better tested against intrusion.
- lower
security:
- use of Windows NT: scp
is mandatory for file transfers to the application server, and
should run as a NT service (see pattern: read protection of
a process internal data by a setUID-like function). This
is quite less secure. Plus, Linux is a more modular system, so
it can be much more simple than NT here.
Alternatives for the account
and group structure on Linux:
- higher
security:
- to
avoid 'others' executing scp, put one sshuser account and its
scp directory in every partnership_i group, and authorize execution
of scp by the group only. Really more secure ?
- lower
security:
- scp is set to not be a
SetUID program. So, each CGI script run by a partner may execute
it under the transfer_i Linux account (see suEXEC). The only
way to be under this account is to run a qualified script, but
scripts may read and write confidential scp internal data (secret
keys), and careful code inspection must verify every script against
this attack.
Previous
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.