gnue-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnue-dev] Appserver/Common Issues


From: Stanley A. Klein
Subject: Re: [Gnue-dev] Appserver/Common Issues
Date: Sat, 23 Nov 2002 21:06:16

Derek and all -

I'm not talking about *requiring* the use of anything.  However, let me
give a better view of what I envision.

Let me start by introducing some security levels.  Many organizations are
beginning to use a variation of this in planning their security.  The
levels can be mapped to the consequences to the organization if data is
disclosed to unauthorized persons or is maliciously tampered-with or
destroyed, or systems made unavailable to legitimate users.

Low security protects against minimal consequences.
Medium security protects against significant consequences.
High security protects against a disaster for the enterprise.

For minimal consequences, some relevant words are nuisance, easily-fixed,
waste of time, and minor embarrassment.  Think about things like a sys
admin having to spend a few hours fixing the problem, users inconvenienced,
or a customer peeved.

For significant consequences, some relevant words are costly,
time-consuming, major embarrassment, and major loss.  Think about things
like a major contract being lost, several major customer relationships
needing to be rebuilt, or a CIO getting fired.

For an enterprise disaster, some relevant words are major blunder, serious
lawsuit, bankruptcy, major criminal investigation, and newspaper headlines.
 Think about things like major accounting fraud, total inability to operate
for an extended period of time, major leak and disruption of critical
corporate strategies and plans, or major violation of laws governing
insider trading.  

Now, as you say, we can't require the XYZ database to use GNUe.  But we can
say that if you want to implement such-and-such a security policy at low
level security using GNUe, you can do it with built-in GNUe capability, and
here's how to configure it.  And if you want to implement the same policy
at medium security using GNUe, you will need to use the Foo or Bar
databases, and the Twiddle or Twaddle operating systems, and here's some
ideas on how to structure and configure your system, and some information
on the GNUe features you will need to use.  And if you want to do it at
high security using GNUe, you will need to additionally do something like
blah, blah, yadda, and yadda. 

I hope this helps clarify the discussion.


Stan Klein


At 12:20 PM 11/23/2002 -0700, Derek Neighbors wrote:
>> > I think there are some database systems that provide access control by
>
>We can not require this.  It goes against the 'mission statement' of the
>project.  It would be far too limiting in database choices.
>
>> > field.  If such a database system is available, I would recommend
using it
>> > to provide control of the price field. The implication for GNUe and
>> > appserver is that the field would need to be traceable from the client
side
>> > through appserver to the database side.  I don't think that was
guaranteed
>> > in the old GEAS.  I hope it can be provided in appserver.
>> 
>> This could work if Appserver logged into the database using the user's
>> username. However, our strategy will more probably be Appserver using
>> it's own logname to log into the database, and therefore having more
>> access rights to the database than the user would have when accessing
>> the database directly.
>
>The security MUST be outside of appserver.  End of story.  The same
>security must work the same for all products and it can NOT require
>appserver.  
>
>Security/Authentication should be happening inside of common.
>
>> > Otherwise, the only way to provide the control is to do it by GNUe
>> > functionality, recognizing (and telling prospective users) that the
>> > security assurance of such an approach is likely to be less than in other
>> > approaches.
>> 
>> If we want to remain portable and database independent, we don't have
>> another choice IMHO than doing access control within Appserver. Whether
>> this is secure or not only depends on the quality of our own code.
>
>I agree to remain portable and database independent security will need
>to reside in GNUe. (it of course can 'use' other security features, but
>cant 'demand them').  I do NOT think it should be in Appserver. It needs
>to be in common.  Appserver then will use it like every other GNUe tool.
>
>-- 
>Derek Neighbors
>GNU Enterprise
>http://www.gnuenterprise.org
>address@hidden
>
>Was I helpful?  Let others know:
> http://svcs.affero.net/rm.php?r=dneighbo
>
>Attachment Converted: "c:\internet\eudora\attach\signat10.asc"
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]