How do I encrypt files in the ZODB
I recently finished my first project in Zope! A file managements system with it's own admin screens. I have recently received requirements for the next version in which the client is asking that the contractors have access to everything but the PDFs that have been uploaded. I know that I could encrypt the PDFs before that they are uploaded but the secretaries that do it it have a hard enough time just creating PDFs. This leads me to my subject. How do I encrypt files in the ZODB? With regards to just PDFs. Something in Python? A product that I missed? A How To that I missed? Upload the files to a external file system that is encrypted? Any sugestions, feedback and general ideas are appreciated. Rob G.
I recently finished my first project in Zope! A file managements system with it's own admin screens.
Congrats.
I have recently received requirements for the next version in which the client is asking that the contractors have access to everything but the PDFs that have been uploaded. I know that I could encrypt the PDFs before that they are uploaded but the secretaries that do it it have a hard enough time just creating PDFs.
I don't follow, in that I don't see encryption in those requirements. Just use Zope's permissions mechanism to set the relevant files (presumably on upload) such that you don't allow whomever you don't want to see them to see them.
This leads me to my subject. How do I encrypt files in the ZODB? With regards to just PDFs.
Something in Python? A product that I missed? A How To that I missed? Upload the files to a external file system that is encrypted?
But if you really want to encrpy something (and, really, security restrictions are just as good unless you're [a] holding very very valuable documents or [b] incredibly paranoid or [c] are at high risk for break-in or internal monkey-business) go find a security library for Python and throw the files through as they come in. It's probably a three-line operation. Where does one get one of those? Try Google on 'python encrypt'. Some promising links from that very search: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/132540 http://www.post1.com/home/ngps/m2/howto.smime.html http://home.pacific.net.au/~twhitema/des.html One could, of course, use one of the encrypted filesystems in lieu or for good measure, keeping in mind that this will only protect from breaches of physical security (an online hack is not troubled by such a thing, in general.) An aside: for encrypted remote filesystems, check out the arcane but cool Self-certifying File System: http://www.fs.net/sfswww/ --jcc
On Mon, Jul 21, 2003 at 01:50:40PM -0700, grissom@qwickconnect.net wrote:
I have recently received requirements for the next version in which the client is asking that the contractors have access to everything but the PDFs that have been uploaded.
GuardedFile, perhaps? A GuardedFile is a Zope File that is accessible by proxy only. http://www.post1.com/home/ngps/zope/gf -- Ng Pheng Siong <ngps@netmemetic.com> http://firewall.rulemaker.net -+- Manage Your Firewall Rulebase Changes http://www.post1.com/home/ngps -+- Open Source Python Crypto & SSL
Hi, Ng Pheng Siong wrote:
On Mon, Jul 21, 2003 at 01:50:40PM -0700, grissom@qwickconnect.net wrote:
I have recently received requirements for the next version in which the client is asking that the contractors have access to everything but the PDFs that have been uploaded.
GuardedFile, perhaps?
A GuardedFile is a Zope File that is accessible by proxy only.
Funny, does this anything a normal file object could not do? :-) Ok, I should read. Regards Tino
On Tue, Jul 22, 2003 at 09:12:38AM +0200, Tino Wildenhain wrote:
Ng Pheng Siong wrote:
A GuardedFile is a Zope File that is accessible by proxy only.
Funny, does this anything a normal file object could not do? :-) Ok, I should read.
The README or HOWTO mentions that you can configure a File manually to be a GuardedFile; the product just saves you some pointy-clicky. ;-) -- Ng Pheng Siong <ngps@netmemetic.com> http://firewall.rulemaker.net -+- Manage Your Firewall Rulebase Changes http://www.post1.com/home/ngps -+- Open Source Python Crypto & SSL
Ng, Thanks for the suggestion. It looks like alot of work went into this and the supporting products. I am still not sure if a guarded file is the right solution for my particular challenge. Here is a little more detail on my app and subsequent new requirements. The file management app contains 4 views that are accessible by 4 member groups and 4 admin groups. Each of the groups has access to at least one view and some have access to all views. The views themselves contain 4 links 3 of the links are direct links to PDFs. The 4th link sends the member or admin to a secondary page with supporting PDFs. Once a member logs in I use DTMl to determine what He or She are able to access. When they click on the file that they are allowed to access they are presented with the PDF. 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. 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. Rob Grissom On Tue, 22 Jul 2003 15:08:45 +0800 Ng Pheng Siong <ngps@netmemetic.com> wrote:
On Mon, Jul 21, 2003 at 01:50:40PM -0700, grissom@qwickconnect.net wrote:
I have recently received requirements for the next version in which the client is asking that the contractors have access to everything but the PDFs that have been uploaded.
GuardedFile, perhaps?
A GuardedFile is a Zope File that is accessible by proxy only.
http://www.post1.com/home/ngps/zope/gf
-- Ng Pheng Siong <ngps@netmemetic.com>
http://firewall.rulemaker.net -+- Manage Your Firewall Rulebase Changes http://www.post1.com/home/ngps -+- Open Source Python Crypto & SSL
On Tuesday 22 July 2003 14:13, grissom@qwickconnect.net wrote:
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.
So what would decrypt the files? If it is something on the server, how do you protect that thing against your bad admin? -- Toby Dickenson - http://www.geminidataloggers.com/people/tdickenson Want a job like mine? http://www.geminidataloggers.com/jobs for Software Engineering jobs at Gemini Data Loggers in Chichester, West Sussex, England
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
participants (5)
-
grissom＠qwickconnect.net -
J Cameron Cooper -
Ng Pheng Siong -
Tino Wildenhain -
Toby Dickenson