Security Model
Older versions of RPyC (1.00 through 2.60) were not designed to cope with security issues. They were meant to be used on local networks or VPNs, where the clients were trusted. Beginning with RPyC 3.0, security became a major consideration in the design of the library, since it is used on open networks. The new security model is described below.
Protocol
The protocol itself no longer uses pickle to serialize transport; instead, we use brine, a small and secure serializer, tailored for RPyC. The pickle module, while simple and powerful, allows the other party to import modules and instantiate custom classes on the host — which can exploited to execute arbitrary code on the host.
The same goes for remote exceptions: again, the remote party can exploit exception instantiation to execute code. To solve that, we use vinegar, a configurable exception serializer. By default it will instantiate only built-in exceptions, but it can be configured to import modules and instantiate custom exception classes, if necessary.
Services
Services allow one party to define exactly what functions and objects will be available to the other party. You can expose only the required set of functions and objects and limit access to their attributes.
Capabilities
RPyC does not utilize ACLs or other security mechanisms; instead, RPyC is based on the concept of capabilities.
Capabilities, in the context of RPyC, are remote object references. One party can only access the capabilities it was given by the other party.
The only way to receive more capabilities is getattr, which can be configured on a per-connection or a per-object basis. Do note that exposing omnipotent functions (like import or open), or granting unrestricted access to dangerous attributes (like __mro__) may breach the security model.
Configuration
The different components of RPyC are now configurable: you can control attribute access, handling remote exceptions and remote pickling. The default configuration is very restrictive, but of course it can be changed to fit your needs. See the API docs for a full listing of the configuration options.
Authenticators
RPyC servers support a feature called authenticators. When a socket is accepted on the server, it is passed to an authenticator object, which is used to authenticate the client (or raise an exception in case. A built-in authenticator is provided for TLS (SSL) sockets, using tlslite: it creates an encrypted connection and authenticates the client using a username and password pair. Custom authenticators can be used instead of the default one — simply pass the authenticator parameter when instantiating the server.
Classic Mode
The classic mode is inherently insecure. As explained under capabilities, it breaches the security model by exposing omnipotent functions (import, exec, etc.) and allowing access to all attributes. This means the client is has unrestricted control over the machine.
The classic mode is intended to be used in secure local networks where the clients are trusted.
However, the classic mode is easiest to deploy and extend. It basically lets you "stretch" your python program across several computers — a very powerful approach to controlling multiple machines, using remote resources transparently, and distributing workload.
