[Zope-dev] Xron and security

[Steve Alexander]

Loren Stafford wrote:
> 
> Thanks, Steve.
> 
> I have few questions below .... 8-) (I'm always better with questions than
> answers.)
> 
> -- Loren
> 
> From: "Steve Alexander" <steve@cat-box.net>
> > Hi Loren,
> >
> > > I'd be glad to listen to well considered proposals for how Xron should
> > > handle security.
> >
> > Consider this a "straw man".
> >
> >
> > On installation, Xron creates a user in the root user folder called
> > "XronUser".
> >
> > Xron is resonsible for setting this user's password. Therefore, it is
> > known to both the Xron product, and also to the root user folder.
> >
> > When a Xron method is run, there is a property that indicates whether it
> > is called anonymously, or authenticated as XronUser.
> 
> Is there a good reason not to always pass authentication in the request? The
> authentication property would have to be stored in the Schedule catalog, and
> I'd like to keep the Schedule as small as possible.

I can't think of a concrete example of when I'd want to have a Xron
method called with no authentication, when authentication is available.

XronUser would be a privilaged user, and it might be useful to run
scheduled methods without using that privilage. However, in the 2.2
security model, you can drop privilage using proxy roles, so I don't
think your suggestion above is a limitation.

So, no, I can't see a good reason not to always pass authentication in
the request.


> > The Xron product could change the password of XronUser every day to a
> > new random value.
> 
> That's more than folks do to maintain secrecy of the "superuser" password.
> Is the extra trouble worthwhile?

I put this in as an example to illustrate that only the Xron product,
and the Zope root user folder need to know the XronUser password. You're
right, it really doesn't need to change every day :-)

However, there should be manage_... method in Xron that will change the
password to a new random value. Then, if people wanted the password
changed every day, they could use a Xron DTML Method to do it :-)

Perhaps also a button somewhere in the Xron product, or in the Schedule,
to call the manage_resetXronPassword method.

> > The domains associated with XronUser could be just localhost.localdomain
> > (not sure about this). Or based on whatever the machine's host-name is
> > (probably better).
> 
> At a virtual-hosted site, how could Xron know what the host-name is?

Xron must know (in some sense) what the host name is now, in order to
use ZClient to call a Xron DTML Method. I guess this is because the URL
to use comes from absolute_url() in Zope.

I'm using Xron 0.0.9 on a virtual-hosted site, and it works.

However, restricting a User's domains doesn't work as I would expect.

The configuration is ZServer behind Apache+ProxyPass. If I put any value
in the "domains" field of a User, other than "127.0.0.1", that User
cannot log in at all. I haven't looked into this particularly yet.


In AccessControl/User.py, login restriction by domain works using
REMOTE_HOST and REMOTE_ADDR from the REQUEST.

I sent myself an email from a Xron DTML Method on two Zope 2.2.1b1
machines, one just running ZServer, the other virtual-hosted as
described above.

In the case of the virtual-hosted server, I get emailed REMOTE_ADDR
127.0.0.1

In the case of the bare ZServer, I get emailed REMOTE_ADDR
my_server's_ip_address

Also, for the virtual server, ZClient seems to choose an appropriate
HTTP_HOST.


So, it seems that the correct domain restriction to use depends on just
how you're using ZServer.

I can think of three ways around this:

  1: Don't bother restricting by domain for XronUser.

  2: Allow a Manager to configure what domains XronUser may log in from.

  3: Use ZClient to call a method in Xron. Xron inspects the REQUEST
passed
     for this method, extracts the REMOTE_ADDR and REMOTE_HOST, and uses
     one of these as the domain restriction.

If you go with 3, there will need to be some button in Xron's management
interface to re-determine the correct domain to use.

If I were writing the software, I'd choose 2, and let the Manager of a
site make the decision.

--
Steve Alexander
Software Engineer
Cat-Box ltd
http://www.cat-box.net