PYRO - Security

Pyro Manual

9. Security

This chapter discusses the security aspects of Pyro, the features you can use to control security, and some important warnings.

Imporant Security Warning
Authenticating using Connection Validators
Customizing authentication using custom Validator
Name Server security plugins
Mobile objects and Code Validators
Firewalls
The pickle trojan security problem, and XML pickling
SSL (secure socket layer) support

Imporant Security Warning

Read this carefully: Pyro is a technology that may easily expose private data to the world, if used incorrectly. While Pyro has some security related functions such as connection validators, it is imporant to understand that exposing a remote object interface in any way (with Pyro, with XMLRPC, or whatever) on an untrusted network (like the internet) possibly creates a big security risk. The risk could be because of a hole in Pyro itself or because of security issues in the used libraries (such as pickle), Python version, or even operating system. Be sure to know what you are doing when using Pyro outside a trusted network and outside trusted applications! Pyro has never been truly designed to provide a secure communication mechanism, nor has it had a security review or -test by a security expert. Read the Pyro software license and DISCLAIMER.

Authenticating using Connection Validators

To guard against unwanted or unauthorized connections, Pyro uses so-called new connection validators. These are objects that are called from the Pyro Daemon to check whether a Pyro server may or may not accept a new connection to that daemon that a client tries to make. By default, there is only one built-in check; the number of connections was limited to a certain amount specifed in the PYRO_MAXCONNECTIONS config item). This check is done by the default connection validator Pyro.protocol.DefaultConnValidator. The fun is that you can supply your own validator object, and that you can therefore implement much more complex access checks. For instance, you might want to check if the client's site is authorized to connect. Or perhaps you require a password to connect.

The default validator already supports passphrase protection as authentication validation. This means that a client that wants to connect to your Pyro server needs to supply a valid authentication passphrase, or the connection is denied. The check takes place automatically (it is performed by the default connection validator), at connect time. The following items are important:

Unless you tell Pyro otherwise, no authentication check is done. Clients can connect anonymously, unless you deny access based on max. connections or client host address.
No passphrases are stored by Pyro, not on disk, not in memory. Pyro uses secure hmac-md5 hashes to compare passphrases.
Server sends an authentication challenge to the client that must be used to generate the actual auth ident (digest of passphrase+challenge). Because the challenge changes for each connection attempt, and thus the required auth ident changes, this scheme is safe against eavesdroppers (auth idents are not reusable).
Once a client is accepted and connected, no further checks are done.
The same passphrases are valid for all objects connected to a certain Pyro Daemon.
Clients can use a different passphrase for each object.
There is no config item to specify the passphrase (because this would be very insecure). Code your own passphrase requester/supplier.

The Name Server and the Event Server can both be instructed to require authentication too.

Look at the "denyhosts", "authenticate" and "user_passwd_auth" examples to see how you can use the connection validators.

How to use the default connection Validator

You can specify the maximum number of connections that Pyro accepts by setting the PYRO_MAXCONNECTIONS configuration item. This limit is always checked when a new client connects.

To enable passphrase authentication, you must tell the Pyro Daemon a list of accepted passphrases. Do this by calling the setAllowedIdentifications(ids) method of the daemon, where ids is a list of passphrases (strings). If you use None for this, the authentication is disabled again. Note that the ID list is a shared resource and that you will have to use thread locking if you change it from different threads. To specify for your client what passphrase to use for a specific object, call the proxy._setIdentification(id) method of the Pyro proxy, where id is your passphrase (string). Use Null to disable authentication again. Call the method right after you obtained the proxy using getProxyForURI or whatever.

If a connection is denied, Pyro will raise a ConnectionDeniedError, otherwise the connection is granted and your client proxy can invoke any methods it likes, untill disconnected.

The default SSL connection Validator

For SSL connections, the Pyro.protocol.BasicSSLValidator is used by default. This is an extension to the normal validator, it also checks if the client has supplied a SSL certificate. See the "ssl" example for details.

Customizing authentication using custom Validator

All authentication logic is contained in the Connection Validator object. By writing your own specialization of the DefaultConnValidator, you can control all logic that Pyro uses on the client-side and server-side for authenicating new connections. You are required to make a subclass (specialization) of the default connection validator Pyro.protocol.DefaultConnValidator. There are two methods that you can use to set your own validator object:

Client side, on the Proxy:: _setNewConnectionValidator(validator)
Server side, on the Daemon:: setNewConnectionValidator(validator)

In both cases, you have to pass an instance object of the validator that you want to use. Don't forget that you still have to use the two methods already mentioned above:

Client side, on the Proxy:: _setIdentification(ident)
Note: the ident that you provide doesn't have to be a single string (or passphrase). It can be any Python object you want, for instance a login/password tuple! It is passed unchanged into the connection validator (see below) that creates a protocol token from it.
Server side, on the Daemon:: setAllowedIdentifications(idents)

The "denyhosts" and "user_passwd_auth" examples show two possible ways to use a custom connection validator.

Below you see the meaning of the different methods that are used in the connection validator class (and that you can override in your custom validator):

class MyCustomValidator(Pyro.protocol.DefaultConnValidator):: ...has to be inherited...

def __init__(self):
Pyro.protocol.DefaultConnValidator.__init__(self) ...required...
def acceptHost(self,daemon,connection):
...called first, to check the client's origin. Arguments are the current Pyro Daemon, and the connection object (Pyro.protocol.TCPConnection object). The client's socket address is in connection.addr. You can check the client's IP address for instance, to see if it is in a trusted range. The default implementation of this method checks if the number of active connections has not reached the limit. (Pyro.config.PYRO_MAXCONNECTIONS) See table below for return codes
def acceptIdentification(self, daemon, connection, token, challenge):
...called to verify the client's identification token (check if the client supplied a correct authentication passphrase). The arguments are: daemon and connection same as above, client's token object (that was created by createAuthToken below), server challenge object that was sent to the client. The default implementation uses createAuthToken to create a secure hash of the auth id plus the challenge to compare that to the client's token. Effectively, it checks if the client-supplied hash is among the accepted passphrases of the daemon (hash of passphrase+challenge) -- if any are specified, otherwise it is just accepted. See table below for return codes. NOTE: you can use the connection argument to store the authentication token (which might be a username). A Pyro object may access this again by getting the connection object self.getLocalStorage().caller and getting the authentication token from there.
def createAuthToken(self, authid, challenge, peeraddr, URI, daemon):
...called from both client (proxy) and server (daemon) to create a token that is used to validate the connection. The arguments are: identification string (comes from mungeIdent below), challenge from server, socket address of the other party, Pyro URI of the object that is to be accessed, current Pyro Daemon. When in the client (proxy), daemon is always None. When in the server (daemon), URI is always None. The default implementation returns a secure hmac-md5 hash of the ident string and the challenge.
def createAuthChallenge(self, tcpserver, conn):
...called in the server (daemon) when a new connection comes in. It must return a challenge string that is to be sent to the client, to be used in creating the authentication token. By default it returns a secure hash of server IP, process ID, timestamp and a random value. Currently it is required that the challenge string is exactly 16 bytes long! (a md5 hash is 16 bytes).
def mungeIdent(self, ident):
utility method to change a clear-text ident string into something that isn't easily recognised. By default it returns the secure hash of the ident string. This is used to store the authentication strings more securely (setAllowedIdentifications). The ident object that is passed is actually free to be what you want, for instance you could use obj._setIdentification( ("login", "password") ) to use a login/password tuple. You have to use a custom connection validator to handle this, of course.
def setAllowedIdentifications(self, ids):
To tell the Daemon what identification strings are valid (the allowed secure passphrases).

(the following only if you subclass from Pyro.protocol.BasicSSLValidator (for SSL connections):
def checkCertificate(self, cert):
...checks the SSL certificate. The client's SLL certificate is passed as an argument. Note: this method is called from the acceptHost method, so you must leave that one as-is or call the BasicSSLValidator base class implementation of that method if you override it. See table below for return codes

The three check methods acceptHost, acceptIdentification and checkCertificate must return (1,0) if the connection is accepted, or (0,code) when the connection is refused, where code is one of the following:

Deny Reason Code	Description
`Pyro.constants.DENIED_UNSPECIFIED`	unspecified
`Pyro.constants.DENIED_SERVERTOOBUSY`	server too busy (too many connections)
`Pyro.constants.DENIED_HOSTBLOCKED`	host blocked
`Pyro.constants.DENIED_SECURITY`	security reasons (general)

Pyro will raise the appropriate ConnectionDeniedError on the client when you deny a new connection. On the server, you'll have to log the reason in the Pyro logfile yourself, if desired. When you accept a connection, the daemon will log an entry for you.

Name Server security plugins

The Name Server supports security plugins, to facilitate access control to the Name Server. Different options are available:

A validator for incoming broadcast server requests (such as 'what is your location' and 'shutdown'). You can now decide what or when such commands are accepted or denied, for instance, based on client IP address.
A new connection validator for the NS server itself (which is a regular Pyro object, and this is the general validator mentioned earlier). With this you can implement very coarse access control to the NS, for instance, deny certain clients based on their IP address.

You'll have to write a Python module that contains the following:

BCGuard() function that returns a BC request validator object, or None.
NSGuard() function that returns a NS new conn validator object, or None.
A class that implements a BC request validator. This class must inherit from Pyro.naming.BCReqValidator. You must override the two methods that check for each command if it is allowed or if it is refused. These are acceptLocationCmd(self) and acceptShutdownCmd(self), and they return 0 or 1 (accept or deny). You can access self.addr to have the client's address (ip,port). You can call self.reply('message') to send a message back to the client. This may be polite, to let it know why you refused the command.
A class that implements a NS new conn validator. See the documentation on connection validators, above, to see how you must implement this.

When you start the NS using the '-s' switch, it will read your module and call the two functions mentioned above to get your validator objects. Make sure your module is in your Python import path. The NS prints the names of the plugins to show that it's using them and then starts. Have a look at the "NS_sec_plugins" example to see how things are done.

Mobile objects and Code Validators

The mobile code support of Pyro is very powerful but also dangerous, because the server is running code that comes in over the wire. Any code can enter over the wire, correct, buggy, but also evil code (Trojans). It's obvious that loading and running arbitrary code is dangerous. That's why you should set a codeValidator for each Pyro object that might load mobile code (mobile objects). The default validator offers no protection: it accepts all code. Be aware that a simple check on the name of uploaded code is not enough to make things safe; the client may supply it's own evil version of the module you thought was perfectly safe. Currently, there is no mechanism to guarantee that the code is safe (for instance using some form of "code signing").

This codeValidator is a function (or callable object) that takes three arguments: the name of the module, the code itself, and the address of the client (usually a (IP,port) tuple). It should return 0 or 1, for 'deny' and 'accept'. Pyro.core.ObjBase, the base class of all Pyro objects, has a setCodeValidator(v) method that you must call with your custom validator function (or callable object). You can set a different validator for each Pyro object that your server has.

The codeValidator is used for both directions; it checks if code is allowed from clients into the server, but also if code is allowed to be sent from the server to clients. In the first case, all three parameters have a value as mentioned above. In the second case (code from server to client), only the name has a value, the other two are None. For example, the code validator shown below is taken from the "agent2" example. It checks if incoming code is from the "agent.ShoppingAgent" module, and outgoing code is from the "objects" package:

def codeValidator(name,module,address):
	if module and address:
		return name=='agent.ShoppingAgent'		# client uploads to us
	else:
		return name.startswith("objects.")		# client downloads from us
   .
   .
   .
mall.setCodeValidator(codeValidator)

Notice that a client doesn't have a code validator. If you're using 2-way mobile code (you've enabled PYRO_MOBILE_CODE on the client), you will silently receive everything you need from the server. This is because the clients usually trust the server... otherwise they wouldn't be calling it, would they?

Firewalls

Using a firewall to protect your network has nothing to do with security in Pyro, but it may affect Pyro. Ofcourse the firewall can be used to fully protect your network for systems outside the firewall; it can make it impossible for those systems to connect to your Pyro servers. But if you want to access Pyro objects from outside the firewall, you may have to take some additional steps. Because they have to do with configuring Pyro, and not with security, they are described in detail in the Freatures chapter.

The pickle trojan security problem, and XML pickling

Security warning: possible trojan attack

By default, Pyro uses the native Python pickle protocol to pass calls to remote objects. There is a security problem with pickle: it is possible to execute arbitrary code on the server by passing an artificially constructed pickled string message. The standard Python Cookie module also suffers from this problem. At the moment of writing, the Python documentation is not clear on this subject. The problem is known to various people. Using Pyro over the internet could expose your server to this vulnerability!!!!

Using the (safe) marshal module is no option for Pyro because we lose the ability to serialize user defined objects. But, if you accept a performance penalty of an order of a magnitude, and more required bandwith (2-4 times more), you can choose to use the safe XML pickling from PyXML or Gnosis_Utils. To enable this, set the PYRO_XML_PICKLE config item to "any" for any implementation (defaults to PyXML), "pyxml" for PyXML, or "gnosis" for Gnosis tools. You need to have the appropriate package installed otherwise Pyro won't start. The server will answer in XML pickled messages also, regardless of the server's PYRO_XML_PICKLE setting. So make sure that the correct XML packages are installed on both ends of the communication. If the server is configured to use PYRO_XML_PICKLE, it will only accept XML pickled requests! This means that if you set this option, your server is safe against pickling attacks.

Please note that at least since Python 2.2 a few pickle security flaws appear to have been removed, and the obvious trojan exploit with pickle no longer works on Python 2.2+. But still, do you trust pickle? ;-) Use PYRO_XML_PICKLE if you want to be safe.

SSL (secure socket layer) support

Pyro supports communication over secure sockets (SSL). See the "ssl" example. Because Python doesn't support server-side SSL out-of-the-box, you'll need the following add-on libraries to enable SSL support:

M2Crypto (0.13 or later recommended)
OpenSSL (needed by M2Crypto)

Why M2Crypto? Because it works for both client and server applications, and is thread safe. Note: M2Crypto needs support for RC5 and IDEA compiled into OPENSSL. Since they're copyrighted these options are normally not included in most major OpenSSL ditributions. You might have to recompile OpenSSL from the sources yourself. Beware that if you use this to upgrade to a new OpenSSL version you also have to recompile OpenSSH since it does a version check on the OpenSSL library.

To start using SSL, you need to tell your Pyro daemon that it must use SSL instead of regular sockets. Do that by passing a prtcol parameter when you create a daemon, as follows:

daemon = Pyro.core.Daemon(prtcol='PYROSSL')

(the prtcol defaults to 'PYRO' ofcourse). All Pyro objects connected to this daemon will get registered in the Name Server using the special PYROSSL protocol, that tells Pyro to use SSL instead of regular sockets. You may also want to add a special SSL connection validator on your daemon that checks the client certificate. The client programs don't need any changes because Pyro knows automatically how to deal with the PYROSSL protocol. There are a few configuration items that deal with the SSL configuration, look for PYROSSL_CERTDIR and the other items starting with PYROSSL. See the M2Crypto homepage or OpenSSL documentation for instructions on how to create your own Certificate Authority- and server/client certificates.

If you're using the Name Server to look up your SSL objects, you won't have to change anything in the client code because the SSL objects are registered with special PYROSSL:// URIs in the NS, and Pyro knows how to deal with that. If you're not using the NS and doing direct PYROLOC:// lookups, you have to change that in PYROLOCSSL:// to tell Pyro it needs to use SSL. (likewise, if you're dealing with PYRO:// URIs yourself, you'll need to change that into PYROSSL://)

Pyro Manual