Yikes! Scary stuff. However, here are some things to consider: a) ExternalFile advertises itself as being a developers/ content authors tool, not really for production. Of course, most folks end up using it for production, anyway... ;-) b) Once created, an ExternalFile cannot be retargetted to point to another file in the file system c) The permission to create an ExternalFile instance is different than the permission to edit one. The permission to create an ExternalFile instance should be assigned judiciously... d) the Zope server should be run as a user that has very limited permissions. e) Even if a user *does* have permission to edit an ExternalFile, they only have whatever permission the user running the Zope server has. If the Zope user (usually "webserver" or something like that) does not have permission to write to /etc/passwd, it doesn't matter if you create an ExternalFile pointing to it, you still can't write to it... However, the points you raise are valid, as they are Zope-specific, and the zope user "webserver" *would* probably have permission to do your (1) and (2) examples. What would you recommend? Perhaps there should be a predefined list of "forbidden" directories for ExternalFiles? The problem is that-- in the development scenario-- the very things you mention below might be what you legitimately *want* to do as a developer. Well, thanks for pointing this out. Let's continue the conversation a bit, perhaps a good solution will reveal itself (even if it is only some kind of warning in the documentation...) Regards, --Craeg PS I am CC-ing the zope-dev mailing list, as I think this warrants a wider audience Jonagustine Lim wrote:
Hi!
I just noticed that it's possible to create or replace any files in the filesystem using the ZMI with ExternalFile installed.
Possible exploits:
1. Use ExternalFile web interface to replace Zope Data.fs
2. Create a .py file in /Zope/Extensions and run it by creating an Extenal Method.
Anyway, I hope you can fix this or put a warning up.
Jon
Hi Craeg, Thanks for your reply... I'd have to respectfully disagree about ExternalFile only for developers because I think it has applications in a production environment as well. 1. Large files. I'd feel more comfortable storing multi-megabyte PDFs and video files in the Linux file system than in Zope for the reason that it would help reduce the unnecessary bloat that Data.fs can grow to. Keeping Data.fs' size in control is also important for backups and general maintenance. I think there is a default 2GB limit to Zope unless python was recompiled with a higher setting. 2. Integration. Being able to tap into the filesystem gives Zope a lot of flexibility when addressing some integration issues. 3. And like you said, most people use it for production anyway. :) For the sake of discussion, would a pre-registration of the ExternalFile-allowed directories, lead to better security? That way, administrators can set how secure/unsecure they want to get by explicitly specifying the folders ExternalFile is allowed to access. Thoughts? Jon --- Craeg K Strong <cstrong@arielpartners.com> wrote:
Yikes! Scary stuff.
However, here are some things to consider:
a) ExternalFile advertises itself as being a developers/ content authors tool, not really for production. Of course, most folks end up using it for production, anyway... ;-)
b) Once created, an ExternalFile cannot be retargetted to point to another file in the file system
c) The permission to create an ExternalFile instance is different than the permission to edit one. The permission to create an ExternalFile instance should be assigned judiciously...
d) the Zope server should be run as a user that has very limited permissions.
e) Even if a user *does* have permission to edit an ExternalFile, they only have whatever permission the user running the Zope server has. If the Zope user (usually "webserver" or something like that) does not have permission to write to /etc/passwd, it doesn't matter if you create an ExternalFile pointing to it, you still can't write to it...
However, the points you raise are valid, as they are Zope-specific, and the zope user "webserver" *would* probably have permission to do your (1) and (2) examples.
What would you recommend? Perhaps there should be a predefined list of "forbidden" directories for ExternalFiles? The problem is that-- in the development scenario-- the very things you mention below might be what you legitimately *want* to do as a developer.
Well, thanks for pointing this out. Let's continue the conversation a bit, perhaps a good solution will reveal itself (even if it is only some kind of warning in the documentation...)
Regards,
--Craeg
PS I am CC-ing the zope-dev mailing list, as I think this warrants a wider audience
Jonagustine Lim wrote:
Hi!
I just noticed that it's possible to create or replace any files in the filesystem using the ZMI with ExternalFile installed.
Possible exploits:
1. Use ExternalFile web interface to replace Zope Data.fs
2. Create a .py file in /Zope/Extensions and run it by creating an Extenal Method.
Anyway, I hope you can fix this or put a warning up.
Jon
===== ------------------------------------------ JONAGUSTINE LIM Email: jonagustine_lim@yahoo.com ICQ: 2084238 ------------------------------------------ __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2
On Thu, Nov 07, 2002 at 11:24:35AM -0500, Craeg K Strong wrote:
What would you recommend? Perhaps there should be a predefined list of "forbidden" directories for ExternalFiles? The problem is that-- in the development scenario-- the very things you mention below might be what you legitimately *want* to do as a developer.
'Jail' the base directory. Files can only be referenced within the jail. Relative paths outside the jail are forbidden. This is what FTP and web servers do, and so should ExternalFiles. A full path (starting with a '/') then starts at the base directory. The base directory should not be configurable through the web. Rather, use an environment variable. Only one directory is needed, as files that need to be accessible can be copied or symlinked. -- Martijn Pieters | Software Engineer mailto:mj@zope.com | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ ---------------------------------------------
OK How about this for the TODO list for ExternalFile: Create a facility whereby ExternalFiles must be created within a set of allowed directory(ies), specified in .../etc/allowedDirectories.txt For example: # # helpful comment goes here # / # allow everything # Or: # /home/webserver/public # public stuff /archive/repository/ # read only dir full of downloaded PDFs /space/temp # temporary area for testing Or: # c:\Documents And Settings # docs dir - the create dialog will list the current set of allowed directories, but not allow changes (changes must be done by hand to the txt file) - there is no default for allowedDirectories.txt I will ship it with no entries, meaning that the product is effectively disabled by default - If no directory is set, ExternalFile.py will raise an Exception at Zope startup time, indicating that at least one allowdir must be set The exception report will include appropriate instructions Comments? --Craeg Martijn Pieters wrote:
On Thu, Nov 07, 2002 at 11:24:35AM -0500, Craeg K Strong wrote:
What would you recommend? Perhaps there should be a predefined list of "forbidden" directories for ExternalFiles? The problem is that-- in the development scenario-- the very things you mention below might be what you legitimately *want* to do as a developer.
'Jail' the base directory. Files can only be referenced within the jail. Relative paths outside the jail are forbidden. This is what FTP and web servers do, and so should ExternalFiles. A full path (starting with a '/') then starts at the base directory.
The base directory should not be configurable through the web. Rather, use an environment variable. Only one directory is needed, as files that need to be accessible can be copied or symlinked.
On Fri, 8 Nov 2002, Craeg K Strong wrote:
OK
How about this for the TODO list for ExternalFile:
Hope it isn't too late discussing this issue. I have tested this product and gave up because of security considerations. And now I have to use it for large files. There is another aspect that this discussion so far has not reached, multi-users, regardless of what mechanism is going to be used. Say my Zope system provides virtual hosting for webmasters (or users in my point of view) of different websites. Not all webmasters want their ExternalFile-linked file be freely accessed to the public. So how if a webmaster links a file belonging to another website? I have an idea, but don't know whether it is possible: set uid. If there is a way Zope server can change uid to a predefined one before accessing an externally linked file, each webmaster will have permission to their own home directory plus some shared directories to which all webmasters have permission. Then I can create system accounts for each webmaster, and map them to the Zope users using a product like SystemUserFolder (is there one?) And if also add the 'jail' option (or chroot to the the webmasters home directory), it will be perfect. Back one step, even there is no way to actually change the uid, we can at least check again it before adding an external file. I'm talking about Unix, I think their are eqivalent way on Windows NT. BTW, I think a similar product, ZFS, is facing the same securiy issue. Wei He
Wei He writes:
... I have an idea, but don't know whether it is possible: set uid.
If there is a way Zope server can change uid to a predefined one before accessing an externally linked file, each webmaster will have permission to their own home directory plus some shared directories to which all webmasters have permission. Forget about this in a multi-threaded process (with almost independent threads).
The "uid/gid" are process global things. Interesting things happen when threads asynchronously change it. In order to be able to switch users, Zope must run with "root" privileges -- a huge security risk.
Then I can create system accounts for each webmaster, Give each webmaster its own Zope process.
Dieter
participants (5)
-
Craeg K Strong -
Dieter Maurer -
Jonagustine Lim -
Martijn Pieters -
Wei He