[Zope-Coders] Re: [ZC] 376/ 2 Reject "copy/paste security"
Christopher N. Deckard
cnd@ecn.purdue.edu
Tue, 7 May 2002 09:01:06 -0500
Comments below...
On 2002/05/07, Collector: Zope Bugs, Features, and Patches ... spoke forth:
> Issue #376 Update (Reject) "copy/paste security"
> ** Security Related ** (Public)
> Status Rejected, Zope/bug+solution critical
> To followup, visit:
> http://collector.zope.org/Zope/376
>
> ==============================================================
> = Reject - Entry #2 by Brian on May 7, 2002 9:26 am
>
> Status: Pending => Rejected
>
> This is actually an under-documentation issue :( This has come
> up in the past, but it has not been considered a security issue.
>
> The reason is that it is not a case of no protection for copy and
> paste, just that the semantics are not always immediately obvious.
>
> The way it works is:
>
> - You have to have "View management screens" in a place in order
> to copy it
>
> - In order to paste an object or objects, you must have the
> permission to *create an object of that type* in the place
> where you are going to paste it.
>
> This is admittedly not perfect, but some time ago when we
> evaluated this we decided that substantially changing the
> current behavior would probably break a lot of existing
> code.
I'll admit, I don't know enough of about it to see
what breaks, but what problems have been encountered?
I haven't noticed any problems with our test systems.
> The canonical way to deal with this sort of issue is to always
> make sure that things you don't people looking at live "above"
> the people you don't trust (and the people you don't trust
> should generally have no rights at all above their specific
> place).
True, but if you think Unix, you can have a directory
accessible by everyone, and then limit access to
specific files by changing its permissions. This
should work the same way in Zope, and it does from
the "View" sense, but not from the management side
of things. The management side is not consistent.
I can turn off permissions on an object (the
oracle connection is a good example because it has
properties that should have limited access). I
can remove the ability for someone to view the
connection string. I can limit access to using
the test capabilities of the connect. I can limit
other things as well. But Copy/Paste gets around
ALL of this. And that is the problem. A user can
circumvent any permission restrictions just by
having access to the management screens. We have
also done this programatically using some of the
methods in the CopySupport module.
> In the example you give, the issue really doesn't concern the
> copy/paste machinery per se - if you have given someone the
There are other checks done in CopySupport to
check for is_copyable and is_moveable. This is
the same kind of thing.
> "View management screens" permission in the place where your
> database adapter lives, he can find out the connect info just
> by looking at it (no copy required), and he appears to have
No. I can turn off access to the properties for
the connection object. Another user account (who
can access the management screens of the folder
where the connection lives) cannot view the
properties and see the connection string. As
stated above, I can also limit access to the test
connection capabilities.
> the "Add (whatever) database connection" in his own area, so
> nothing stops him from creating a totally new connection to
> your database without regard to copy/paste.
> It sounds like you really want to fix the security settings
> so that those users have no rights above their appropriate
> level and that their rights are appropriate at "their" level.
I want the management side of things to act like
other acl or permission based security that I've
used. Unix and Windows. If I don't have "read"
on a file, I can't copy it. Unix inforces this.
In Zope, my argument is that Copy/Paste circumvents
all of the setting of permissions that I can do.
I think there should either be a new permission,
like "Copy and Paste" (or something like that), or
it could be based off of the access contents
information permission. That seems pretty logical
to me. If I can't access the contents info, I
should be able to copy the object.
I hope that helps expain my argument for a check
in there.
-Chris
>
> Hope this helps!
>
> -Brian
> ________________________________________
> = Request - Entry #1 by chrisdeckard on May 2, 2002 5:18 pm
>
>
> Uploaded: "CopySupport_canCopy.diff"
> - http://collector.zope.org/Zope/376/CopySupport_canCopy.diff/view
> It is common knowledge that we can restrict access
> to an object by taking away many of the permissions
> from the security manager in the ZMI. Especially
> in the case of some objects like Oracle database
> connections, you don't want other people to be
> able to snag your "connect string" which contains
> username and password information.
>
> However, if a user has access to any folder on the
> system, they can programatically (and in some
> cases use the ZMI) copy the objects to anohter
> location. For example, if a user can view the
> management screens in a folder, they can copy an
> object, paste it to another location, give his
> self Manager local roles, and then view the "connect
> string". This works basically for every object.
>
> The problem is the CopySupport._canCopy method,
> which always returns 1 (true). It looks like this
> should be overridden for special products, but the
> base functionality should do some basic
> permission checking to determine if the object is
> copyable or should be copied.
>
> Attached is a diff for OFS/CopySupport which adds a
> check to _canCopy to look for the "Access contents
> information" permission.
>
> -Chris
> ==============================================================
>
--
--------------------------------------------------------------------
Christopher N. Deckard | Lead Web Systems Developer
cnd@ecn.purdue.edu | Engineering Computer Network
http://www.ecn.purdue.edu/ | Purdue University
---- zlib.decompress('x\234K\316Kq((-J)M\325KM)\005\000)"\005w') ---