[Zope-dev] Re: Unsecure design of ExternalFile

[Jonagustine Lim]

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