Re: Security framework issues

[Derek Neighbors]

> 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 

Personally I think it is taking too much focus too early.  Perfect
security with nothing working is perfectly useless security.  

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

Every sanctuary has its price.  A secure computer is one with the power
off.  That of course isnt very useful.  The trick is finding the proper
mix of security and usability.  As you state here a reasonable level is
one that doesnt require more than is currently used in the project.
(i.e. demanding an esoteric operating system version is practical
(today))

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

GNUe has always been about choices.  Not only should we allow people to
choose what platform GNUe runs on we should allow them choices in how
much or how little security to implement.

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

I agree with this more than anything.  Security is way to easy to 'argue
about' with no implemenation than most things.  If its not readily able
to implement at this point its probably not worthy of too much
discussion other than lets note this for later discussion.

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

Both appserver and reportserver are slightly unique in that they are
'daemons' more than applications so they will have 'security concerns'
above the user/data type stuff that the other applications have.

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

There are lots of other daemons out there in which we can gather
information on how they secure themselves.

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

This needs to happen in common.  Just because one uses 'middleware'
doesnt mean 2 tier doesnt have teh same requirements.  All RBAC and data
type security needs to be handled in a re-usable way.

> So currently, I do not see any way that the appserver can get by 
> without having a security layer.

Common shoudl have this layer and appserver should use it.  Same as DB
abstraction...

> 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?

These are good questions.  Again reportserver likely will have same
issues so its another thing probably suited for common.

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

Its half a dozen one way or another.  I have used both types and there
are practical issues going with either way.  I tend to agree though to a
large extent a single login is probably better by appserver.

> 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 dont think anyone can comment.  If you feel GNUe isnt usable to you
then it isnt.  GNUe is usable to a great deal of people now.  It
certainly wouuld be vastly improved with RBAC, but its far more
important to get things functional for some and get it out the door than
it is to get it perfect and have no one use it because it doesnt exist.

> 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 agree.  There is lots of good stuff in there.

 
-- 
Derek Neighbors
GNU Enterprise
http://www.gnuenterprise.org
address@hidden

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=dneighbo

signature.asc
Description: This is a digitally signed message part