[prev in list] [next in list] [prev in thread] [next in thread] 

List:       intermezzo-devel
Subject:    Re: Kerberos and PAGs
From:       "Peter J. Braam" <braam () clusterfilesystem ! com>
Date:       2001-11-09 17:28:41
[Download RAW message or body]

On Fri, Nov 02, 2001 at 10:24:30AM +0100, Jacob Gorm Hansen wrote:
> On Wed, Oct 24, 2001 at 09:22:58AM -0600, Peter J. Braam wrote:
> >  - how does the kernel on the client make sure not to release
> > information to other users -- this requires a PAG associated with the
> > authentication of a process. 
> 
> I've read through some of your posts to the coda-list and lkml from 1998, and
> it seems the newpag() patch was rejected at that time. Do you still view PAGs
> as the way forward?

Yes.  The nature of work on security is that everybody starts chipping
in and it is difficult to get something accepted.  I do think PAGs are
good, and in fact it is hard to imagine doing this without a PAG
concept. 

> 
> About authorizing updates; We thought about calculating a hash like:
> 
> crypt ( authenticator + kml_modification ) , where crypt is a one-way hash like
> MD5 or SHA, and storing/sending it with each entry in the kml.
> 
> In that way, the server could keep a backlog of all authenticators that were 
> ever logged in, and use that for checking whether changes stem from a once valid
> login.

That would work. Another thing that could be done is to let the server
hand out tamper proof and crypted capability based on the ACL.

> 
> If we just store the same authenticator or capability for every record, then
> a stolen KML could be used to insert arbitrary changes.

Indeed you'd need to protect authenticators and/or capabilities.

> 
> Maybe this discussion should move to the intermezzo-list btw.
> 
> Best,
> Jacob

-- 

_______________________________________________
intermezzo-devel mailing list
intermezzo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/intermezzo-devel

[prev in list] [next in list] [prev in thread] [next in thread]