[Zope] How do I encrypt files in the ZODB

J Cameron Cooper jccooper@jcameroncooper.com
Tue, 22 Jul 2003 12:45:43 -0500


>
>
>The concern is not with the users and I don't want to have
>to authenticate a user every time they
>request a file. It sounds like if I read the Guarded file
>How to correctly; thats what will occur
>after installing and using a GuardedFile.
>
Authentication is done by Zope for every request made. It's just the 
nature of the beast. (And it doesn't have a significantly high 
computational overhead.) You, as developer, really shouldn't have very 
much to do with it; if you do, you're working too hard.

Set the permissions on the objects and code such that links display only 
if permissions are available. (In a loop, this is 'skip_unauthorized'.) 
Your users log in, and are presented only with links to objects to which 
they have access. When they try a download, Zope checks their 
permissions and serves up the content if everything clicks. You can even 
do this with your "views".

This is not to say that you don't have some strage requirements or that 
it would be an easy retrofit, of course.

>The main concern is with our contracted Web Server Admins.
>Even if I were to set up roles and
>security for our contractors they could still migrate
>data.fs to a new ZOPE server set up an
>emergency user account and access the ACL Users Folder.
>Correct? This is the assumption I am
>working on.
>  
>
If you have something for which this is a valid problem, the only real 
solution is to get admins you can trust. There's almost no way to secure 
yourself against God, and that's what a sysadmin is to his computer. You 
have two possible other avenues:

1) encrypt sensitive data before you store it in the ZODB, either client 
or server side. Then decrypt on the client side, because if you decrypt 
in software that can be hijacked (and you're right, it's easy enough to 
jack Zope if you have filesystem access to it) you're wasting your time. 
And if you have clients like mine, they don't want to deal with 
decrypting things.

2) don't allow your sysadmins to be root. Someone you trust is root, and 
your hired admins are almost root. Restrict the ZODB from everyone but 
the Zope user and root, and don't let your almost-root admins su to that 
user. And if untrusted people have physical access to your machine, you 
should put it on an encypted filesystem, too. A lot of sysadmins would 
balk at this, and you have to end up with a sysadmin on staff, at least 
part-time, which presumably you were trying to avoid in the first place.

Even if you do one of these, or even both, it's still a dicey 
proposition whether you'll actually be able to keep out an attacker in 
such a priveledged position: you'll have to defend against single-user 
mode, local root exploits, tainted software, and other problems. 
(Approach #1 is pretty strong, but not foolproof. Both together are 
better, but only in that it'll take longer and require more diverse 
skills.) Frankly, there's no good way around an admin you don't trust.

Although I'd love to hear some creative suggestions.

       --jcc