[ZODB-Dev] ZEO and Security

[Bill Anderson]

On 07 May 2001 16:04:25 -0400, Jim Fulton wrote:
> Bill Anderson wrote:
> > 
> > On 07 May 2001 11:06:20 -0700, Michel Pelletier wrote:
> > > On 7 May 2001, Bill Anderson wrote:
> > >
> > > > On 07 May 2001 10:09:34 -0400, Chris McDonough wrote:
> > > > > Ssh tunnelling is an effective workaround for now.
> > > >
> > > > Not really, as that just encrypts the traffic from the client. it does
> > > > nothing to prevent, say, Bob from doing things he should do,such as
> > > > messing around with Joe's data.
> > >
> > > Security is outside the domain of the database.  ZODB does not know
> > 
> > Since when??
> 
> Since I designed ZODB. I chose to make ZODB as small as possible
> and require many features, such as security and indexing, to be
> implemented at a higher level (the application level wrt ZODB, 
> which could still be an infrastructure level wrt some 
> "application").

Sorry, I meant 'since when is database security not the damain of the
databse?' :)

Due to the use-pattern of the ZODB, I agree that the ZODD should not
neccessarily be the place to implement the security I am asking for,
which, again, I feel should be done by ZEO.
> 
> I think that the problem you raise is a valid and interesting one.
> I'm interested in seeing what ideas we can come up with to address
> it.
> 
> Two general approaches come to mind:
> 
>   - Build something that sits between ZODB and the application.
>     For example, using an OO-RPC like CORBA or Pyro sort of takes
>     this approach. I think that these ideas have some merit. It would
>     be interesting to see how they play out in practice.
> 
>   - Build a custom storage that implements *some* security model.
>     It would have to work at the object/record level and would need
>     authentication at the connection level. (We do need, eventually, 
>     to have the ability to authenticate ZEO connections.)  This model
>     would probably be much more course grained than Zope's, but far more
>     fine grained than what you typically get with an RDBMS.

I feel the later is the 'better' choice. I hadn't thought much about a
custom storage that did it, though that is certainly an option. it could
be done independant of ZEO development (been looking over ZEO2 stuff on
the wiki.

I was considering playing with the zrpc.py as one possible route (hack).
I thought I might be able to hack som eosrt of crude mechanism in there
for 'fun'. Then I thought about a custom root() that had hooks for
authenticating against _something_ Like i said in my first post, most of
my ideas have died on the birthing table, but if people lie, I can post
some of them for idea generation pruposes.

It occurs to me that in the zrpc may be _one_ place to put at least a
ZEO Client authentication. If it was done such that one could use a
basic authentication token, rather like a license key, you could at
least get basic auth, such that the client is authenticated to connect.


<random thought>
Hmm what about a checksum verification of the client code ... if I had a
checksum of the client code, and stored that where the server could get
to it, and required the client to send it's checksum ... that may be
useful. Something like that would have to happen in the connect phase,
though.
</random thought>


Anyway, it seems that if teh estimated timeframe for a "SecureZEO" is
this fall, now would be a good time to start generating and discussing
ideas. perhaps with that, some of us could start toying with various
ideas.

Bill