Re: Security framework issues

[Neil Tiffin]

Stanley & Reinhard,

I believe the discussion regarding security is an important one and I 
am glad someone is addressing it.  With that said I also would like 
suggest some additional direction.  I am not a security expert so if 
I have something wrong here I hope someone will point it out.

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.

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.

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.

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.

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).

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.

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?

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.

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.

Thanks for listening.

Neil
address@hidden