[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(fwd) Re: Security framework issues
Stanley A. Klein
(fwd) Re: Security framework issues
Sat, 23 Nov 2002 12:10:23
This is one of two messages on this thread that we forgot to cc: to the
list. I'm forwarding it so we can document the discussions.
>Subject: Re: Security framework issues
>From: Reinhard Mueller <address@hidden>
>To: "Stanley A. Klein" <address@hidden>
>X-Mailer: Ximian Evolution 1.0.5
>Date: 22 Nov 2002 15:26:40 +0100
>Am Mit, 2002-11-20 um 22.50 schrieb Stanley A. Klein:
>> 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).
>You may find this funny or not, but I share this experience :-)
>My problem is that I'm expected to actually help design an appserver...
>Anyway, we've sorted out a lot of things in our meeting.
>> 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.
>Yes. That's part of appserver's job. The other important part is the
>enforcement of all kinds of "business logic".
>> 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.
>From my point of view, security is not a "function" of a program, it is
>something that has to go all through the code. In that respect, I regard
>security much like quality or stability.
>However, some special aspects, for example authentification, are handled
>by specific code and in this fields we can (should) reuse functions that
>are already there, in our example we could base the authentification
>mechanism on PAM.
>> 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.
>agree. MHO is that we should use PAM.
>> 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.
>The points in my item 5 can't be handeled by the operating system. We
>can't protect user data using the operating system if the user data is
>stored in a database. At least, I wouldn't know how.
>GNU Enterprise project
- (fwd) Re: Security framework issues,
Stanley A. Klein <=