Re: Security framework issues

[Stanley A. Klein]

Reinhard -

Oops.  I think somewhere along the line one of us did a "reply" instead of
a "reply to all".  I will forward the other messages to the list.

Other comments interspersed.


At 02:55 PM 11/23/2002 +0100, you wrote:
>Stan,
>
>I'm not sure if you didn't cc your mail to the list on purpose, so I
>answer in private, too. If you want you may forward both mails to the
>list to have it archived.
>
>Am Fre, 2002-11-22 um 18.59 schrieb Stanley A. Klein:
>> >> 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".
>> >
>> 
>> Hmmm.  That's an interesting way to describe it.  We run into
>> security-related issues when business logic begins to look like either
>> security policy or accounting integrity requirements.  Then "enforcing"
>> business logic becomes an enforcement issue, also sometimes known as a
>> security issue.  :-)
>
>Yes. Agree.
>
>> >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.
>> 
>> Some aspects of security are functional.  Other aspects are indeed elements
>> of quality.  Some people use the term "information assurance" to describe
>> security, and that reflects your viewpoint of viewing security like quality
>> and stability.
>
>Ok. Starts to look like we're actually on the same track and just having
>language problems :-)
>
>> BTW, I think you have been somehow combining identification and
>> authentication and making up a new word. :-)
>
>Well, what did I say? Language Problems?
>Thanks for telling me anyway. :-)
>


I give you all the credit in the world for carrying on a complex technical
discussion in English when it isn't your native language.  If I had to
carry on a discussion in any language other than English, it would have to
be strictly limited to talking about the pen being on the table.  :-)


>> >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.
>> 
>> I have always (I think) said we should look first to the operating system,
>> then to the database, then to the internal functionality of GNUe itself.
>> 
>> We need to be careful to give users the flexibility to use the operating
>> system or the database if they can do the job.  I once had a discussion
>> regarding the old GEAS design that left me with the impression that GEAS
>> took away that kind of flexibility, i.e., you had to use the security
>> provided by GEAS because you couldn't trace any data from the user client
>> side to the database side.  I hope appserver will provide better
flexibility.
>
>I'm not sure if I understand what you mean here.

This is really an echo of an email discussion I had with Jan, where he
mentioned the issue of flexibility, which has really been in the background
as a major issue all along.

>
>Maybe we would want to discuss this in IRC when we meet there next time.


I do better with email than with IRC.  I sometimes look in on IRC, but it
often seems that when I have the time to talk nobody else seems to be
active.  Also, I think much better doing email than I do with IRC messaging.


Stan