[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