Re: Security framework issues

[Stanley A. Klein]

Reinhard -

I've lettered my responses to avoid confusion with your numbered comments:

A.  I don't claim to know that much about appserver or the concept of
application servers.  Every time I read or hear about application servers,
they seem to be different things to different people.  Everyone seems to
use the same buzzwords to mean different things that they seem to assume
everyone else defines exactly as they do (and therefore they have no need
to explain what they mean). 

B.  My own view of appserver is that clients connect to appserver, and
appserver connects to wherever the data is, shielding the clients from the
details and complexity of the data locations and databases or other formats
in which the data is stored.

C.  Security needs to be built-in from the start.  Adding security later is
very difficult and less likely to succeed.  The trend is toward security
certification under standards such as the Common Criteria (ISO IS-15408).
There was a recent announcement that Windows 2000 had been certified under
the Common Criteria at Evaluation Assurance Level (EAL) 4 (which is the
highest level in the US for non-government certification).  I have also
seen a comment that the certification conditions are very restrictive, such
as no network connection allowed.

Tony Stanco at George Washington University has a project to security
certify Security Enhanced Linux, which will be a loadable module of the
Linux 2.6 kernel.  This will be a pilot project for certifying the security
evaluation of a free/open-source software project.  He is working with the
people at NIST and NSA, which are the US representatives on the
international consortium of information security agencies that developed
the Common Criteria.  Under the rules of the consortium, certification in
any one country is valid for all the others.  It is my understanding that
they will try to achieve EAL-2 within about a year and EAL-4 within a few
years.  Part of the Common Criteria evaluation considers the development
methods, which will need to be carefully interpreted for use on
free/open-source projects. 

If someone were to express interest in the security of GNUe, it would be
much easier to show that it is possible to provide security by installing
and using Security Enhanced Linux (or some other certified operating
system) to protect the appropriate GNUe files than to claim that GNUe
provides its own security using its own code.

D.  In looking at security it is important to look beyond how something is
supposed to operate when it is working properly and consider how it can be
attacked and defeated.  Then we need to block the ability of a malicious
intruder to exploit the potential vulnerabilities we have identified.

E.  If it is feasible to use the operating system or database security for
protecting the appserver, we should do so.  For example, we should study
carefully to see if there is a way to do all login, authentication, and
password storage in the operating system and avoid doing it in the
appserver.  If it turns out we need to do some of these things in the
appserver, we should do them using flat files, which are much more easily
protected using the operating system, rather than using the database, which
is less easy to protect.

F.  On the points in your item 5, the same considerations apply as in E
above.  There may well be some access controls that can only be handled
within appserver.  If these arise, we should recognize ourselves and make
it clear to our users that these functions are insecure against a
sophisticated attacker.


Stan Klein


At 03:49 PM 11/20/2002 +0100, Reinhard Mueller wrote:
>Stan,
>
>sorry for this late answer, but I was buried in work and just got my
>head above water again.
>
>IMHO, we have to regard the security topic as a set of separate issues
>that even don't relate too much to each other.
>
>(I'm talking n tier here)
>
>1. How appserver connects to the database, and whether we let normal
>users send direct SQL over _that_ connection. Whether we have a separate
>user for the appserver in the database, and where we store that user's
>password.
>Must be handled in appserver.
>
>2. How secure the connection between appserver and database is, e.g.
>whether the connection is encrypted, tunneled through a VPN, etc. How
>secure the database port on the db backend machine is, how it is
>protected against denial of service etc.
>Can and probably will be handled by database and/or operating system.
>
>3. How the user authentificates to the application server, how we safely
>transmit the password over the network, how application server checks
>whether the password is correct, where the user passwords are stored.
>Must be handled in appserver. However, it might be possible to use PAM
>for this.
>
>4. How secure the connection between the client and the appserver is
>(same issue as 2. basicall).
>Can and probably will be handled by the operating system and/or the
>transport layer (GNU RPC). Some points might have to be addressed in
>appserver.
>
>5. Once the user has logged into appserver, what access he/she has. What
>data he/she can se, and what data he/she can change. What procedures
>he/she can call.
>This must be done by appserver 100%.
>
>Point 5 could be a system which defines
>class/condition/property/user/access tuples.
>For example:
>* employee/NULL/NULL/fred/read would mean that fred has read-only access
>to the employee table.
>* employee/NULL/salary/NULL/none would mean that all users except
>defined exceptions do not see the salary property. To those users, the
>appserver behaves as if the salary property wasn't defined.
>* employee/NULL/salary/joe/write would mean that joe may read and write
>the salary of all employees.
>* employee/department="10"/salary/jim/write would mean that jim can only
>read and write the salary of all employees that work in department 10.
>* employee/department.leader=$USER/salary/NULL/write would mean that
>every department leader can only change the salary of employees working
>in his department.
>
>Of course this is not a proposal for a specific syntax. But I think you
>get the idea.
>
>If I understood correctly, Jan had the idea of implementing exactly this
>using "views" on business objects, that means the actual business object
>definition looks different depending on who looks at it.
>
>Thanks,
>Reinhard
>
>-- 
>Reinhard Mueller
>GNU Enterprise project
>http://www.gnue.org
>
>Attachment Converted: "c:\internet\eudora\attach\signatu3.asc"
>