Extending Erlang for Safe Mobile Code Execution

Extending Erlang for Safe Mobile Code Execution
- Dr Lawrie Brown
  - Australian Defence Force Academy
  Dr Dan Sahlin
  - Computer Science Labs, Ericsson Telecom
Introduction
- want safe mobile code in Erlang
  - programs are remote, untrusted
  - must constrain execution environment
- current work focus is procedural lgs
  - eg Java, Safe-TCL, Omniware, Telescript
- here consider functional lgs
- currently proof-of-concept research
Why Mobile Code?
- mobile agents
  - server lets agent code migrate to it
- applets
  - client requests applet load and run
- outsourced code
  - run application but control access
- fault isolation
  - isolate application components
Issues
- Run-time safety
  - will runtime system guarantee the program will behave as per source?
  - procedural languages can't
  - functional languages usually do
- System safety
  - will the run-time system control access to resources per some policy?
Why Erlang?
- Erlang is a functional language
  - fac(N) when N>0 -> N * fac(N-1);
  - fac(0) -> 1.
- for programming real-time systems
  - real-time, concurrent, robust, non-stop, distributed, external interfaces
    - Echo = spawn(echo,loop,[]),
    - Echo ! {self(),"Here is a message"},
    - ....
    - loop() -> receive
    - {From,Msg} -> From ! Msg, loop() end.
Erlang Uses 1
- currently used in a number of large telecommunications applications
- Mobility Server
  - intelligent call control giving personal numbers for Conson PBX mobile users
  - 486 modules, 230000 lines Erlang, 20000 lines C, 39 programmers
  - in production, on time, under budget
  - one of largest functional programs ever
Erlang Uses 2
- Distributed Resource Controller
  - link human operators with various audio devices and database systems
  - 40 modules, 12800 lines Erlang, little C
  - 9 programmers took less than 1 year from definition
  - in production, eg Danish PTT, 2 sites 638 operators, 400 audio ports
- other projects under development
Erlang Uses 3
- general comments and experiences
- time to market
  - shorter time, better quality
- performance
  - sufficiently good for real telecomms
  - in large systems loss of speed wrt C more than compensated for by ease of development and maintenance
- real-time garbage collection works
Limitations in Erlang now
- pure functional use safe
- only dangerous with side-effects
- pids/ports too powerful
  - forgeable
  - unrestricted control over resource
    - eg can kill any process on system
- processes have same "world-view"
  - modules, names, resources, servers
- no remote code loading in context
Safer Execution in Erlang
- need controlled access to processes and external resources (ports)
  - make these data types capabilities
- want custom world-view
  - implement a hierarchy of (sub)nodes
    - registered names
    - modules available
    - resource limits
- need remote code loading in context
Capabilities
- unique, unforgeable resource name with associated rights to use
  - <Type,Node,Value,Rights,Private>
- for nodes/pids/ports/user capas
- possible implementations
  - crypto hash check, validated by node
  - password (sparse) key to table of valid capabilities managed by node
- my research about getting this right!
Nodes
- each Erlang system to support a hierarchy of (sub)nodes
- provide a distinct context
  - registered names
    - control which servers are accessible
  - modules available
    - module name aliasing
      - support remote loading, safety renaming
  - resource limits on processes
    - partition & constrain use of system resources
Remote Code Execution
- support "remote" code loading and execution in context
  - to support mobile agents, applets
- module refs in "remote" modules
  - load requested module from remote system, not from local system
  - each module has a "context"
- like code mobility whilst executing
  - several processes, upon request
SafeErlang
- Naesar & Sahlin
  - Masters project, late 1996
- subnodes provide distinct context
  - modules, resource limits
- capabilities control access
  - encrypted (must decrypt for all use)
  - nodes & pids only
- remote module loading (mids)
  - for mobile agents
SSErl
- Brown
  - sabbatical research, 1997
- subnodes provide distinct context
  - names, module aliases
- capabilities control access
  - nodes, pids, ports, user capabilities
  - both crypto hash & password
- remote module loading
  - still working on dynamic context
Custom Safety Polcies
- formal proof program safe is hard
- idea is to filter messages to servers
  - using pattern-matching in function clauses to specify & implement
- using safer erlang system as base
- want easy policy spec & implement
- most services use client-server
  - standard "gen-server" server control
Conclusions
- rationale & approach for a safer erlang execution environment
  - capabilities
  - nodes
  - remote code loading
- to support mobile agents, applets, outsourced code, fault isolation
- base for custom policy support
Further Information
- see papers and software on web
  - http://lpb.canb.auug.org.au/adfa/papers/ssp97/
Types of Capabilities
- need capability data in clear
  - for efficient guards/pattern matches
    - <Type,Node,Value,Rights,Private>
- crypto hash check value
  - node has private key to compute/check
  - small vulnerability to search attacks
- password (sparse) value
  - key into node table of valid capabilities
  - any guess must verify with node
Performance Impact
- space
  - expect approx same no capas as pids/ports now (user capas are extra)
  - capas only a bit larger, not significant
  - password capas do need extra table
- time
  - check value used on creation
  - can tag "local" capas as checked
  - "remote" capa use has comms delays
Lawrie.Brown@adfa.edu.au / 05-May-98