[OpenAFS-devel] Re: openafs - proposed cache security improvement

Sean O'Malley omalleys@msu.edu
Tue, 27 Mar 2007 12:05:59 -0400 (EDT)


On Tue, 27 Mar 2007, Jeffrey Altman wrote:


> > Thus I have offered more confusion. :)
>
> You are doing a good job of it.  :)

I appreciate the encouragement. =) I will try to be more straight-forward
as to the issues I see, by asking a lot of questions. =)

-but first.
I was not dealing with kerboros much at all. The hacked kaserver
would no longer be a kerberos server. I was just thinking that would be a
quick hack. You get a "ticket/key" to wrap the afs-client data in as your
cryptography for the session transport, etc. A quick hack. nothing
special. It would probably easier to rewrite it completely to be honest
especially after perusing the code.
---

> If you want to protect the content of the cache, then it must be
> encrypted with a key that is known not to any user but to the cache
> manager.  Hence, my recommendation that you turn on encryption of the
> cache directory.  Doing so will ensure that only the account under which
> the AFS Cache Manager runs will be able to read or write data from the
> cache.

How portable is this solution? What is the speed hit? How do i maintain
the security of the cache manager key?

> The AFS Cache Manager is disconnected mode (when that is available) will
> locally restrict access to files based upon the AFS ID and the directory
> ACLs.  Only users that are permitted to access the data based upon its
> last known state would be permitted to do so.

What about reboots? or is this information going to be stored somewhere
if so what is protecting it? (my windows box likes to crash, but it is
probably hacked..)

Should I trust my network storage solution for my security or my local
machine for security? If I am understanding what you are saying correctly,
I might as well just set up a sync script to my afs space, copy the files
locally and not even bother with an afs client at all until I am back on
the network to dump my files because the client isn't actually doing
anything. Or am i misinterpreting?

What about multiple local machine user accounts that use the same token.
Like my dev environments and my user environments all on the same machine.
I also have multiple afs accounts that i use frequently from all of the
local accounts.  The one user account may have a token i synced the cache
manager with, but then I switch local machine user accounts but wish to
access my afs space from that account.. am I hosed trying to access that
data because it is attached to a specific local user account? What about
trying to use two afs accounts from the same local account?

> Without a valid token, the cache manager will not be able to write data
> back to the server on behalf of the user.  That is a limitation that
> disconnected mode will have to address.

That is a given. But can you write back to the cache manager while it is
unplugged? How do you verify that the user the local machine authenticated
was actually the real afs user that is now authenticated trying to sync
the changed files? It sounds paranoid but if you have covered your bases,
then adding this type of support probably wouldnt be much work even though
it may seem unnecessary and it does add some protection at least for the
integrity of the files in the network storage solution even though the
data itself was compromised.

Those are all the issues i have come up with so far.  I hope it was a bit
less confusing this time around. :)


--------------------------------------
  Sean O'Malley, Information Technologist
  Michigan State University
-------------------------------------