[Zope3-dev] Security: Permissions to use software (?)

[Jim Fulton]

I suggest that one should generally not require a permission to use
software.   We generally don't need to protect algorithms. Rather, we
need to protect resources that software may access.

In general then, utilities, modules, factories, etc. should not
require permissions to use them. An exception is software used to
access system resources (e.g. databases or files).  This means that
access to factories and most utilities should be unconditionally
allowed, by specifying zope.Public as the required permission.
Likewise for module attributes that only perform computation.

If we want to allow access to external resources, we need to do so
carefully.  If we do provide access and require a permission for the
access we need to be aware of the limitations of the security policy
in effect.  For example, the security policy currently used in Zope 3
allows only local grants for most principals.  It does allow global
grants for global principals,  which are defined in ZCML.
This means that access to a global object requiring a permission other
than zope.Public will usually be disallowed.  So, for example, requiing
a permission to access a global module attribute is equivalent to
disallowing access to principals not defined via ZCML. Alternate
security policies could avoid this.

Another way to provide access to system resources is to give them
locations. We do this now with local database connections.  Of course,
the factories for creating these local system accessors need to be
designed carefully.

Adapters (of various kinds, including views) are software that augment
existing objects.  Generally, we don't need to protect the adapter
code itself. We only need to protect the resources it accesses.  This
is complicated by the fact that adapters can be created from trusted
or from untrusted code.  Untrusted code can only directly adapt
objects that are security proxied.  Adapters created directly by
untrusted code need no special protection because the objects that
they adapt are protected.  We need to worry about adapters created
from trusted code, because they will often adapt unprotected
(non-security-proxied) objects.

I suggest that the simplest strategy for most adapters is to:

- Unconditionally allow access by requiring the zope.Public
   permission,

- Assure that the objects they adapt are security proxied.  This can
   be automated, but we need a way, in ZCML, to indicate this should
   happen.

This strategy applies to adapters that:

- Need to be accessed by untrusted code

- Don't access any external resources directly in their code (as
   opposed to accessing resources indirectly through the objects they
   adapt)

- Don't *need* unfettered access to the objects they adapt

Adapters that aren't accessed by untrusted code don't need security
declarations.

Adapters that access external resources have the same issues as other
software that accesses external resources, as described above.  It
should be very unusual for adapters to directly access external
resources. perhaps it should be considered a design flaw for them to
do so.

It is possible that adapters might need access to the objects they
adapt that is not provided to untrused code. This would be the case
for adapters whos purpose, at least in part, is to provide moderated
access that is otherwise not permitted. In this case, the adapter
needs to require an appropriate permission. (Note that, with the
current security policy, adapters that require a permission probably
need to be given a location in the objects they adapt.)

Questions? Comments?

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org