Safe Local XMLRPC

[Michael Urman]

Hi. I'm a user of python for about 3 years now. I've written a
client-server application that uses SimpleXMLRPCSer ver and
xmlrpclib.Serve rProxy to communicate. It's intended to be used by a
single-person as a backend and GUI frontend. I've got it running
great. Much stabler than my custom RPC I'd tried before.

I've used the default support available by these classes. Thus it will
run on a potentially public TCP/IP port. As the application backend
allows, among other things, saving files to the local filesystem, this
would be a clear security hole in the wild. Restricting it to
localhost would be a start, but not sufficient for multi-user systems.

It looks like it should be easy to modify both classes (or create
similar composite classes) that used unix-domain stream sockets. I
tried at one point and I think I got the server side, but without a
working client side it was impossible to tell. Is there a better way
to do this, or might someone point to references or sample code for
creating a unix-domain SimpleXMLRPCSer ver and xmlrpclib.Serve rProxy?

Thanks!
-m

[Diez B. Roggisch]

Re: Safe Local XMLRPC

> I've used the default support available by these classes. Thus it will[color=blue]
> run on a potentially public TCP/IP port. As the application backend
> allows, among other things, saving files to the local filesystem, this
> would be a clear security hole in the wild. Restricting it to
> localhost would be a start, but not sufficient for multi-user systems.[/color]

This might not be the answer you want, but I'd personally ditch xmlrpc and
switch to something like pyro or even corba and implement a "real"
authentication theme. They are easy to use, provide a full OO-style
interface and are even faster than xmlrpc.

Part of the problems you're facing stem from the stateless nature of xmlrpc
(and soap, for that matter). That allows everybody to access the API
without prior authentication. It requires some effort to implement a
authentication/authorization scheme over xmlrpc. What usually is done in
xmlrpc in similar situations like yours is that there is a

authenticate(us er, password)

function that will return a handle on success that has to be passed to all
subsequent calls to other functions. All this because the handle can't be
associated with each and every xmlrpc request (in soap that can be done,
but its undstandarized. )

With corba/pyro, authenticate would return an object that implicitely has
all the state needed - nameley who created the connection - and then you
don't have to bother about that anymore.

Switching to pyro shouldn't be much more than a few lines of code, more or
less only subclassing your server from Pyro.core.ObjBa se instead of
SimpleXMLRPCSer ver.

--
Regards,

Diez B. Roggisch

[Michael Urman]

Re: Safe Local XMLRPC

[Sorry, I previously replied to Diez offlist, and probably to a
spam-protected address at that. Here's that reply and my followup
after reading up on pyro
]
On Sat, 12 Mar 2005 11:08:31 -0600, Michael Urman <murman@gmail.c om> wrote:[color=blue]
> On Sat, 12 Mar 2005 14:12:21 +0100, Diez B. Roggisch <deetsNOSPAM@we b.de> wrote:[color=green]
> > This might not be the answer you want, but I'd personally ditch xmlrpc and
> > switch to something like pyro or even corba and implement a "real"
> > authentication theme.[/color]
>
> I don't have a problem with switching interfaces so long as I can keep
> my (admittedly useless) feature of multiple simultaneous connections.
> I am hoping to avoid writing an authentication method, as some slight
> missteps there could lead to real trouble later; this is why I was
> hoping to do unix-domain socket transports which I could just set to
> read-write only by the owner on the filesystem itself.
>[color=green]
> > With corba/pyro, authenticate would return an object that implicitely has
> > all the state needed - nameley who created the connection - and then you
> > don't have to bother about that anymore.[/color]
>
> If I can get the authentication that I'm looking for that cheaply,
> then this does indeed sound like the way for me to go. I'm not worried
> about supporting remote connections, or anything of that nature, so
> local identity is sufficient. I'll look into pyro; conveniently
> there's a debian package for me to try.
>
> Thanks Diez!
> -m
>[/color]

Hmm. On inspection, pyro seems to be really heavy, what with its
requirement of a pyro-nameserver, and using TCP as the transport. I
think I'd still prefer convincing a variant of SimpleXMLRPCSer ver and
xmlrpclib.Serve rProxy to use unix domain sockets and using filesystem
security to limit access to the owner.

Thanks again,
-m

[Michael Urman]

Re: Safe Local XMLRPC

Thanks for your time everyone; I got it XMLRPC working over unix
domain stream sockets. In case people are interested, here's the
pieces I put together. I'm sure they throw away a little flexibility,
but they work for my purpose. Any pointers to make the code more
robust, or do less total overriding of should-be-arguments
appreciated.

-m

from SocketServer import UnixStreamServe r
from SimpleXMLRPCSer ver import SimpleXMLRPCDis patcher,
SimpleXMLRPCReq uestHandler
from xmlrpclib import ServerProxy, Fault, Transport
from socket import socket, AF_UNIX, SOCK_STREAM

# Server side is pretty easy - almost a direct copy of SimpleXMLRPCSer ver
SOCKPATH = 'testsock'
class UnixStreamXMLRP CServer(UnixStr eamServer, SimpleXMLRCPDis patcher):
def__init__(sel f, addr=SOCKPATH, requestHandler= SimpleXMLRPCReq uestHandler):
self.logRequest s = 0 # critical, as logging fails with UnixStreamServe r
SimpleXMLRPCDis patcher.__init_ _(self)
UnixStreamserve r.__Init__(self , addr, requestHandler)

# Client is a lot more complicated and feels fragile
from httplib import HTTP, HTTPConnection
class UnixStreamHTTPC onnection(HTTPC onnection):
def connect(self):
self.sock = socket(AF_UNIX, SOCK_STREAM)
self.sock.conne ct(SOCKPATH)

class UnixStreamHTTP( HTTP):
_connection_cla ss = UnixStreamHTTPC onnection

class UnixStreamTrans port(Transport) :
def make_connection (self, host):
return UnixStreamHTTP( SOCKPATH) # overridden, but prevents IndexError

proxy = ServerProxy('ht tp://' + SOCKPATH, transport=UnixS treamTransport( ))
# proxy now works just like any xmlrpclib.Serve rProxy

[Diez B. Roggisch]

Re: Safe Local XMLRPC

> Hmm. On inspection, pyro seems to be really heavy, what with its[color=blue]
> requirement of a pyro-nameserver, and using TCP as the transport.[/color]

The nameserver is purely optional. Regarding the overhead of transport -
well, I didn't check pyro on that, but corba is 10-100 times faster over
the network than soap/xmlrpc. So while the local loopback _might_ be slower
(I'm not even sure about that) than the unix socket, marshalling data as
xml has its own cost overhead.


--
Regards,

Diez B. Roggisch

[Stephen Waterbury]

Re: Safe Local XMLRPC

Diez B. Roggisch wrote:[color=blue]
> ... corba is 10-100 times faster over
> the network than soap/xmlrpc. ...[/color]

I'm not challenging these statistics (because I don't know),
but I would be interested in the source. Are you referring
to the results of an actual benchmark, or something more
subjective?

Steve

[Diez B. Roggisch]

Re: Safe Local XMLRPC

Stephen Waterbury wrote:
[color=blue]
> Diez B. Roggisch wrote:[color=green]
>> ... corba is 10-100 times faster over
>> the network than soap/xmlrpc. ...[/color]
>
> I'm not challenging these statistics (because I don't know),
> but I would be interested in the source. Are you referring
> to the results of an actual benchmark, or something more
> subjective?[/color]

Mainly personal expirience (I run a corba server that has an xmlrpc server
on top to adapt the interface for php, which has limited corba facilities),
but there are benchmarks on this that support my claim:

http://csdl.computer.org/comp/proceedings/apsec/2002/1850/00/18500084abs.htm

--
Regards,

Diez B. Roggisch