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

[Jeffrey Altman]

Sean O'Malley wrote:
> On Tue, 27 Mar 2007, Jeffrey Altman wrote:

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

You can choose to replace Kerberos by defining a new rx security class
and by replacing the token format and ....

Then after defining the new security class every AFS service needs to be
updated to support it and you have to put in code to provide for
backward compatibility, ....

This is a non-trivial job.  rxk5 has taken Marcus and Matt over a year.
rxgk is taking even longer primarily because we don't have any dedicated
resources to working on it.

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

Encrypting the cache directory is an operating system and file system
specific issue.  It really has nothing to do with AFS at all.  On
Windows you create an account under which the AFS Client Service is
executed, you create the directory into which the cache will be created,
you set the ACLs so that the AFS Client Service is the only entity that
can access the directory, and you turn on encryption on the directory.

The security of the key is maintained by Windows as part of the
account's hive.

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

At least on Windows, the bindings between logon sessions and the AFS
credentials is maintained in the registry.

If your system crashes the cache data is lost.

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

There is no disconnected mode at present in the AFS client.  If you want
access to files off-line, you must copy them locally.

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

You can only access data that you have a token for.

You can already access multiple AFS cells from the same logon.  This is
supported by afscreds.exe and Network Identity Manager.

You cannot have two AFS Tokens for different accounts within the same
cell at the same time.

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

The only thing you have is local account authentication.  Tokens are
encrypted with the AFS Server key.  The cache manager cannot decrypt
them and so cannot determine what the identity of the AFS user is other
than what the local user claimed it should be.

What matters is the AFS tokens that are in the possession of the cache
manager when the data is sync'd back to the AFS file server.

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

Jeffrey Altman
Secure Endpoints Inc.