Re: [Zope] Import from file via management-interface
I found it very disturbing having to get my .zexp exports into the subdirectory 'import' of the server and then using the management-interface to do the actual import.
I found it inconvenient, too. (Not disturbing, though.) And I had to implement my own uploading scheme via web. But as anything that is put into the file system, I thought that there must be some security reason. At least I know that's why the Extensions folder is there. Is this (existence of import folder) really a shortcoming of Zope, or is there some security reason why .zexp cannot be uploaded directly from browser? Can someone somehow write a destructive external method, and then upload it via .zexp? regards, Hung Jung _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.
you can write anything destructive, whether it is an external method, a DTML Method, or basically anything. At least if the only way you can import .zexp's is from the import directory, then only people with access to the zope file structure can import stuff...that will usually be restricted to system administrators or superuser people. terry Hung Jung Lu wrote:
I found it very disturbing having to get my .zexp exports into the subdirectory 'import' of the server and then using the management-interface to do the actual import.
I found it inconvenient, too. (Not disturbing, though.) And I had to implement my own uploading scheme via web. But as anything that is put into the file system, I thought that there must be some security reason. At least I know that's why the Extensions folder is there.
Is this (existence of import folder) really a shortcoming of Zope, or is there some security reason why .zexp cannot be uploaded directly from browser? Can someone somehow write a destructive external method, and then upload it via .zexp?
regards,
Hung Jung
_________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at http://profiles.msn.com.
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
-- Terry Kerr (terry@adroit.net) Adroit Internet Solutions Pty Ltd (www.adroit.net) Phone: +613 9563 4461 Fax: +613 9563 3856 Mobile: +61 414 708 124 ICQ: 79303381
Hi Terry, Terry Kerr wrote:
you can write anything destructive, whether it is an external method, a DTML Method, or basically anything. At least if the only way you can import .zexp's is from the import directory, then only people with access to the zope file structure can import stuff...that will usually be restricted to system administrators or superuser people.
Hm. I dont see the point here. First you can restrict the ability to Export/Import in the users role. Second, the either the superuser has to be bothered with imports or you have to grant all the people access to the file system. This would be much lesser security as beeing able to import via web. May be I schould have a deeper look at the ownership-problem. Giving the importing user ownership over all objects (s)he imports as long it is not the superuser, schould do the trick. Regards Tino
On Sat, Sep 09, 2000 at 09:39:33AM +0200, Tino Wildenhain wrote:
Terry Kerr wrote:
you can write anything destructive, whether it is an external method, a DTML Method, or basically anything. At least if the only way you can import .zexp's is from the import directory, then only people with access to the zope file structure can import stuff...that will usually be restricted to system administrators or superuser people.
Hm. I dont see the point here. First you can restrict the ability to Export/Import in the users role. Second, the either the superuser has to be bothered with imports or you have to grant all the people access to the file system. This would be much lesser security as beeing able to import via web.
May be I schould have a deeper look at the ownership-problem.
Giving the importing user ownership over all objects (s)he imports as long it is not the superuser, schould do the trick.
The problem is not so much ownership of the objects imported, but the type of objects that can be instanciated from a pickle (the export format wether XML or binary, consists of pickled classes). You can create _everything_ from a pickle, as long as there is a class definition for it; including a monitor client. I can open up a high port on your machine that'll let me connect to your Zope process in a python interpreter prompt. Then your server is my oister. Allowing imports from arbitrary paths will let me exploit security holes in other internet daemons on your machine to create a pickle file for import; preferably the /tmp directory as it is world writeable. Restricting imports to one directory allows you to be much more restrictive as to who can write there. You can set up restricted FTP access or even only allow scp (ssh encrypted file transfer) for trusted people to upload exports to the Zope import directory if you need to give others import rights. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ | ZopeStudio: http://www.zope.org/Products/ZopeStudio -----------------------------------------------------
Hi, Martijn Pieters wrote:
On Sat, Sep 09, 2000 at 09:39:33AM +0200, Tino Wildenhain wrote:
Terry Kerr wrote:
you can write anything destructive, whether it is an external method, a DTML Method, or basically anything. At least if the only way you can import .zexp's is from the import directory, then only people with access to the zope file structure can import stuff...that will usually be restricted to system administrators or superuser people.
Hm. I dont see the point here. First you can restrict the ability to Export/Import in the users role. Second, the either the superuser has to be bothered with imports or you have to grant all the people access to the file system. This would be much lesser security as beeing able to import via web.
May be I schould have a deeper look at the ownership-problem.
Giving the importing user ownership over all objects (s)he imports as long it is not the superuser, schould do the trick.
The problem is not so much ownership of the objects imported, but the type of objects that can be instanciated from a pickle (the export format wether XML or binary, consists of pickled classes).
You can create _everything_ from a pickle, as long as there is a class definition for it; including a monitor client. I can open up a high port on your machine that'll let me connect to your Zope process in a python interpreter prompt. Then your server is my oister.
Thats badly true, but importing of a whole bunch of objects is also often needed. IIRC does pickle only handle instance data but not class code. (although I see using of marshal in the import code which does in fact import code as oposite to pickle) Importing instance data schould not be a problem since it can only work if the user in question has access to the classes. This access is already handled by permissions. Moreover we could restrict importing via web to the superuser at all.
Allowing imports from arbitrary paths will let me exploit security holes in other internet daemons on your machine to create a pickle file for import; preferably the /tmp directory as it is world writeable. Restricting imports to one directory allows you to be much more restrictive as to who can write there.
You can set up restricted FTP access or even only allow scp (ssh encrypted file transfer) for trusted people to upload exports to the Zope import directory if you need to give others import rights.
Uh, do you know any ssh-daemon for windows? ;-) Regards ;-) Tino
On Sat, Sep 09, 2000 at 03:54:25PM +0200, Tino Wildenhain wrote:
The problem is not so much ownership of the objects imported, but the type of objects that can be instanciated from a pickle (the export format wether XML or binary, consists of pickled classes).
You can create _everything_ from a pickle, as long as there is a class definition for it; including a monitor client. I can open up a high port on your machine that'll let me connect to your Zope process in a python interpreter prompt. Then your server is my oister.
Thats badly true, but importing of a whole bunch of objects is also often needed. IIRC does pickle only handle instance data but not class code. (although I see using of marshal in the import code which does in fact import code as oposite to pickle) Importing instance data schould not be a problem since it can only work if the user in question has access to the classes. This access is already handled by permissions.
No it isn't. Web access to class instances is handled by permissions. Unpickling will cause class instantiation in the python process, where you have no control over what get's created. You can create a custom unpickling class, but one that would handle the Zope range of objects would be, in Jim's words "tricky".
Moreover we could restrict importing via web to the superuser at all.
This would completely defeat your idea that people besides the superuser should be able to import. Apart from being a security risk.
Allowing imports from arbitrary paths will let me exploit security holes in other internet daemons on your machine to create a pickle file for import; preferably the /tmp directory as it is world writeable. Restricting imports to one directory allows you to be much more restrictive as to who can write there.
You can set up restricted FTP access or even only allow scp (ssh encrypted file transfer) for trusted people to upload exports to the Zope import directory if you need to give others import rights.
Uh, do you know any ssh-daemon for windows? ;-)
Sorry, no, but that's because I never looked. I am sure there are other secure options for file transfer for Win32 available though. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ | ZopeStudio: http://www.zope.org/Products/ZopeStudio -----------------------------------------------------
Martijn Pieters wrote:
No it isn't. Web access to class instances is handled by permissions. Unpickling will cause class instantiation in the python process, where you have no control over what get's created.
Surely you could pipe this process through the Zope security process?
You can create a custom unpickling class, but one that would handle the Zope range of objects would be, in Jim's words "tricky".
...then again, maybe not :-( *sigh* Chris :-)
you can write anything destructive, whether it is an external method, a DTML Method, or basically anything. At least if the only way you can import .zexp's is from the import directory, then only people with access to the zope file structure can import stuff...that will usually be restricted to system administrators or superuser people.
But if there was a Can Import From Web role than you could control who could import and who couldn't. Granular Security is a strong point of Zope. We should strive to use it.
participants (6)
-
Chris Withers -
Hung Jung Lu -
Martijn Pieters -
Steve Drees -
Terry Kerr -
Tino Wildenhain