#
# $XORP: xorp/docs/libxipc/security.txt,v 1.2 2004/07/09 04:40:51 pavlin Exp $
#

		XRL Security: An outline and starting point

				April 2003			      

			       Orion Hodson

Introduction
=-=-=-=-=-=-

The XRL library provides interprocess communication for XORP
processes.  The exchange of IPC data may happen over any number of
transport protocols: socket based (UDP, TCP, HTTP), Sys-V IPC (shared
memory, sys-V messages), Unix signals, in-process function calls.  The
Finder process provides resolver functionality to XORP processes and
allows them to find suitable IPC transports.

Since XORP is dependent on the the XRL library for IPC, it had better
be secure.  This document describes what is currently implemented and
presents some directions that we could take.  The content is intended
for discussion purposes and not set in stone.

Section 1: Securing the Finder from the outside world
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

o Host based access control to the Finder			[Implemented]

Processes talk to the Finder with a Finder Transport Protocol.  At the
time of writing, the only Finder Transport Protocol implemented uses
TCP and a UDP version shall probably follow in future.  As a first
step towards security, the Finder and the FinderClient library,
support an API that accepts packets from a restricted host list.  The
finder obtains the host list from command line arguments presented at
start-up.

o Finder interface binding					[Implemented]

The Finder also supports binding to a specified interface address, and
as will result will filter communication that arrives on unexpected
interfaces. [ Implemented as Finder -i <ifaddr>, but turned off by
default ]

In the case of a distributed XORP router, it is conceivable that the
signaling traffic, ie the on-the-wire transport protocols and Finder
communication, would use a dedicated network with just the distributed
hosts interface per host exposed on the network.

Section 2: Securing XORP applications from the outside world
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

o Method name randomization					[Implemented]

XRL processes implement target specifications and support calling
interfaces.  When processes start-up, they register which interfaces
they support and which transport methods are available for each
particular XRL.  The XRL target and interface specifications
are documented in the XRL interface and target files in the project
source tree (xorp/xrl/interfaces, xorp/xrl/targets) and are publicly
viewable.

It is conceivable that a remote attacker with knowledge of an Xrl
target and it's supported interface might send requests to a range of
ports on a Xorp router in an attempt to execute an Xrl.  To raise the
bar on this attack, the Finder tells clients during the registration
process a unique name for the XRL being registered.  Clients
transparently map the unique name into the methods specified in the
interface and target files.

    Process A registers processA/interfaceA/method, the Finder accepts
    the registration and tells Process A that it should interpret
    requests of processA/interfaceA/method-19292939abfa as a call to
    processA/interfaceA/method.

    Process B wishes to invoke processA/interfaceA/method and contacts
    the Finder.  The Finder tells process B that the method exists but should
    be dispatched as processA/interfaceA/method-19292939abfa
	 
An external host without access to the finder not only has to
determine the relevant port to send it's request to, it also has to
guess the method name that the relevant process will accept for it's
request.  At present, the munged method name is the original method
name with a generated 16 digit hex number trailer.

The generator function is make_cookie() in:
			xrl/libxipc/finder_ng_xrl_target.cc

Section 3: Securing processes within XORP
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

o XRL access control lists					[Proposed]

One of the goals of XORP is to allow researchers to run experimental
code on production routers.  In the absence of mechanism, this
requires a degree of trust between the researchers and the router
administrators.  To simplify matters, an administrator would probably
want to restrict access to XRL interfaces on a per process basis.  We
could conceivably implement this as a two step mechanism.

Firstly, we need to authenticate processes as they register with the
finder.  This could be as simple as providing a shared keys to the
Finder and Processes, each process uses the key to generate a hash
value to authenticate itself with the Finder on start-up.

Secondly, the Finder obtains authenticated process access control
information from the file system.  The access control information would
indicate which processes could access which XRLs.  The starting point
for permissions could be generated by running a XORP router and seeing
which processes call which XRLs and then manually editing those
settings.  For new processes the administrator could explicitly state
which XRL's are permitted to be called.  In practice, the researches
would probably provide an access control file for their process that
the administrator could review and install at the same time as
installing their binary.