Re: Security framework issues

[Reinhard Mueller]

Neil,

thanks for your input.

Am Sam, 2002-11-23 um 18.35 schrieb Neil Tiffin:
> 1. Security discussions should include both a "how we could/should do 
> it now" and "how we should do it right" sections.  I believe keeping 
> up with the secure linux project is important but we won't be using 
> this operating system anytime soon.  So any security discussion 
> should include what will work now with Python and Debian.

You might be right that we should consider both, near future (that is,
what will work "now") and far future. However, I tend to concentrate
more (too much?) on the near future part, as for the far future I've
made the experience that "planning means replacing accident by error".

> 2. I believe the project is committed to a Windows version.  So we 
> have to have alternatives for Windows.  Alternatives does not mean 
> the exact same level of security but rather a way for it to work.  It 
> will always be up to the implementation team to decide if a 
> particular implementation is secure enough.

Agree partly. In our 3-tier environment, I think we will have two
typical install variants:
a) Single-PC-install (Home office, very small office) - typically no
access control needed.
b) Network install - most of them would have a serious operating system
for Appserver.

> 3. I have a hard time following only conceptual discussions and 
> determining if they are implementable.  Any conceptual discussions 
> should include enough practical directions that someone could start 
> working on the code (like what libraries could be used etc).  This 
> also forces the discussion down to earth somewhat and I do not think 
> it limits the discussion as much as it makes the discussion more 
> valuable to the current project.

Agree. The "abstractness" of the discussion is something that makes it
hard for me, too.

> 4. The issue that I would like to understand (and excuse me if this 
> seems a bit basic) is how the appserver port will be protected.  The 
> way appserver works is that it is a service that is running on a 
> server waiting for connections.  When appserver gets a connection it 
> responds by providing the information according to the API.

This is a very important question. We need a security expert with good
techical know-how to address this.

> Are we going to use some operating system protection that (maybe 
> TCPwrappers, if it does this) will assure that anyone connecting to 
> the port has the proper credentials?  With my current understanding I 
> don't see how this will work. Or is appserver going to be responsible 
> for determining that a connection is allowed.  My experience has 
> shown that business middleware needs finer security than the 
> operating system provides (Role based has been suggested and I agree 
> conceptually with this but don't understand how it is implemented).

The current plan of the API is that anybody connecting to the port has
to authenticate before being able to call other functions. Much like
most other protocols work, at least this is my understanding.

> In the enterprise there are lots of security issues that will need to 
> be addressed in the middleware.  For example some detail fields are 
> OK to expose as long as someone does not have access to the summary 
> of the fields.  For example a data entry clerks may see total sales 
> currency for an order but management may not want them to see total 
> sales for the month or year.  The reverse may also hold in that 
> summary data may be ok if someone does not have access to the 
> details.  For example payroll, departmental totals are ok, while 
> individual salaries are not.
> 
> So currently, I do not see any way that the appserver can get by 
> without having a security layer.

Agree on this.

> 5. When the connection is made to appserver I would like to 
> understand what credentials will be passed to the appserver so that 
> it knows it can allow the connection and what authority that 
> connection has.  For example will a token be passed with each 
> request? Will a separate application be responsible for providing and 
> validating these tokens?  Will this be stateless or will a connection 
> be established and then all communications with that IP be valid?  Or 
> some other method?

I think we are targeting at a stateful connection, that is at
connect-time a username and a password (probably encrypted) is sent to
appserver, and that remains valid for all subsequent operations using
this connection.

But again, this has to be tested how secure it is.

> 6. Based on my experience the appserver should communicate with the 
> database using its own credentials and users should communicate with 
> appserver with their own credentials.  I am currently responsible for 
> an application that does not work this way and there is no way to 
> secure bypassing the middleware with lower level tools using the 
> users credentials.

Agree.

> 7. I know others do not agree with me, but there is no way GNUE in 
> its current state could be used in our organization without a better 
> security framework (unless I don't understand it).  If GNUE had a 
> good security framework then I could be replacing system we use now 
> that are based on windows and are security nightmares.
> 
> I am looking forward to a new draft of teh security document.  There 
> is a lot of value to have security built in from the start.

I would rather say, "there is a lot of value to have a security concept
from the start".

Security is much like multi-currency, or many other things: some won't
even need once it in 100 years, but if you need it, you need it badly.
:-)

Thanks,
Reinhard

-- 
Reinhard Mueller
GNU Enterprise project
http://www.gnue.org

signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil