Applications using Erlang Web 2.0 Security & Privacy (W2SP) 2010 - - PowerPoint PPT Presentation

applications using erlang
SMART_READER_LITE
LIVE PREVIEW

Applications using Erlang Web 2.0 Security & Privacy (W2SP) 2010 - - PowerPoint PPT Presentation

Enforcing User Privacy in Web Applications using Erlang Web 2.0 Security & Privacy (W2SP) 2010 May 20, Berkeley, California, USA Ioannis Papagiannis , Matteo Department of Computing Migliavacca, Peter Pietzuch Imperial College London


slide-1
SLIDE 1

Enforcing User Privacy in Web Applications using Erlang

Ioannis Papagiannis, Matteo Migliavacca, Peter Pietzuch Department of Computing Imperial College London David Eyers, Jean Bacon Computer Laboratory University of Cambridge Brian Shand CBCU National Health Service

Web 2.0 Security & Privacy (W2SP) 2010 May 20, Berkeley, California, USA

slide-2
SLIDE 2

2

User Privacy in Web Applications

  • Which is longer, the United States Constitution or

Facebook’s Privacy Policy?

  • Facebook’s Privacy Policy: 5,830 words
  • United States Constitution: 4,543 words

[NYT, May 12, 2010]

  • Twitter 0 followers bug
  • Tweet "accept," followed by "@" and user name
  • The other user starts following you automatically (!)

[Official Twitter Blog, May 10, 2010]

W2SP 2010

slide-3
SLIDE 3

3

User Privacy in Web Applications

  • User data privacy must be guaranteed independently
  • f the application’s functional correctness

W2SP 2010

slide-4
SLIDE 4

4

User Privacy in Web Applications

  • Code should access only relevant user data and keep

them isolated from other users’ data

W2SP 2010

slide-5
SLIDE 5

5

Use Case: Privacy in Microblogging

A microblogging system should guarantee:

  • 1. Messages from a publisher component shall be

delivered only to authorised subscribers’ components.

[User A’s messages will only go to Users B and C]

  • 2. Authorised subscribers shall not be disclosed to any
  • ther publisher or subscriber component.

[User B will not know about User C]

  • 3. Subscription authorisation requests from a

subscribing component shall be delivered only to the relevant publisher’s component.

[Only User A can authorise a new User D]

W2SP 2010

slide-6
SLIDE 6

6

IFC for Microblogging

W2SP 2010

slide-7
SLIDE 7

7

IFC for Microblogging

W2SP 2010

slide-8
SLIDE 8

8

IFC for Microblogging

W2SP 2010

slide-9
SLIDE 9

9

IFC for Microblogging

W2SP 2010

slide-10
SLIDE 10

10

IFC for Microblogging

W2SP 2010

slide-11
SLIDE 11

11

IFC for Microblogging

What happens when data belonging to different users has to be processed by a single component?

W2SP 2010

slide-12
SLIDE 12

12

Microblogging: The Dispatcher

Multiple publishing components have to use a single dispatcher to reach the relevant subscriber components

W2SP 2010

slide-13
SLIDE 13

13

Microblogging: The Dispatcher

W2SP 2010

Multiple publishing components have to use a single dispatcher to reach the relevant subscriber components.

slide-14
SLIDE 14

14

Solution

  • Each User’s data must be kept separate, but

applications are usually monolithic

  • Compartmentalize the application in multiple isolated

components, one per user

  • Granularity?

W2SP 2010

slide-15
SLIDE 15

15

Solution

Language Isolation Issue C OS Processes ~100kB per process

W2SP 2010

  • Each User’s data must be kept separate, but

applications are usually monolithic

  • Compartmentalize the application in multiple isolated

components, one per user

  • Granularity?
slide-16
SLIDE 16

16

Solution

Language Isolation Issue C OS Processes ~100kB per process Java OS Threads Limited isolation: static fields,

  • bject locks, runtime channels

W2SP 2010

  • Each User’s data must be kept separate, but

applications are usually monolithic

  • Compartmentalize the application in multiple isolated

components, one per user

  • Granularity?
slide-17
SLIDE 17

17

Solution

Language Isolation Issue C OS Processes ~100kB per process Java OS Threads Limited isolation: static fields,

  • bject locks, runtime channels

PHP JavaScript OS Processes Spawning a new runtime on top of spawning a new OS process

W2SP 2010

  • Each User’s data must be kept separate, but

applications are usually monolithic

  • Compartmentalize the application in multiple isolated

components, one per user

  • Granularity?
slide-18
SLIDE 18

18

Erlang

  • Sequential Part:

functional language, single assignment, dynamic typing

  • Concurrency:

share nothing concurrency, message passing

  • Erlang is great for IFC
  • Isolation is free
  • Asynchronous message passing can be naturally

combined with label checks

  • Processes are lightweight (~100B, runtime implementation)

W2SP 2010

slide-19
SLIDE 19

19

Erlang: Example

  • Receiver Process:

primeTester() -> receive {calculate, Pid, Number} -> Result = isPrime(Number), Pid ! {result, Result} end.

  • Sender Process:

test(0) -> done; test(N) -> pid=spawn(primeTester), pid ! {calculate, self(), N}, receive {result, Result}-> io:format(“~w”,[Result]) end, test(N-1) end. Spawning processes is fast! Async message passing is the

  • nly way* of communication!

You can want to have lots of them!

W2SP 2010

slide-20
SLIDE 20

20

Supporting IFC in Erlang

  • Attach labels to pids
  • new_tag()

creates a new tag for the calling process

  • spawn(TagsAdd, TagsRemove, ...)

changes the tags of the spawned process (≠ caller’s tags)

  • send(TagsAdd, TagsRemove, ...)

changes the tags of the message (≠caller’s tags) checks labels

  • delegate(PidReceiver, Tag, Type)

gives privileges over a tag to another process

W2SP 2010

slide-21
SLIDE 21

21

Erlang for Microblogging I

  • 1. Messages from a publisher shall be received only by

authorised subscribers.

W2SP 2010

(untrusted code)

slide-22
SLIDE 22

22

Erlang for Microblogging I

W2SP 2010

  • 2. Authorised subscribers shall not be disclosed to any
  • ther publisher or subscriber.

(untrusted code)

slide-23
SLIDE 23

23

Erlang for Microblogging II

  • 2. Authorised subscribers shall not be disclosed to any
  • ther publisher or subscriber.

W2SP 2010

(bug prevention)

slide-24
SLIDE 24

24

Erlang for Microblogging III

  • 3. Subscription authorisation requests from subscribers

shall be delivered only to the relevant publisher.

W2SP 2010

(bug prevention)

slide-25
SLIDE 25

25

Experimental Setup

  • Erlang Library that provides the IFC API
  • Measure throughput in terms of messages per second
  • #publishers=#subscribers, 10 subscriptions/subscriber
  • Ignored orthogonal issues like message persistence

Comparison between:

  • Python

[represents scripting languages]

  • Erlang (no IFC)

[Dispatcher per publisher, better multicore performance]

  • Erlang (IFC)

[Anonymisers plus label checks]

  • Erlang (IFC + caching)

[cache and reuse of label checks]

W2SP 2010

slide-26
SLIDE 26

26

Evaluation

W2SP 2010

slide-27
SLIDE 27

27

Limitations & Discussion

  • Complexity
  • Applications have to handle tags/privileges manually
  • Deciding upon a tag allocation scheme is challenging
  • Handling tags routines must be correct for secure operation

 Policy languages may come to the rescue

  • Persistence
  • Messages must be stored permanently
  • Fetching and storing data but be compatible with labels

 Extend Mnesia to be label aware

  • Scalability
  • Inactive users must be offloaded from RAM
  • Scalability depends upon the ability to keep in memory only

the required state

 Introduce a primitive to hibernate/restore a process

W2SP 2010

slide-28
SLIDE 28

28

Conclusion

Erlang is an attractive approach for web applications that use IFC to provide privacy guarantees:

  • Isolation of components is free
  • Asynchronous message passing is the norm in IFC

systems

  • Scales well in multicore architectures

Web applications can provide IFC-enabled Erlang APIs and hosting facilities for untrusted extensions

  • The web application has to disseminate tags to components

according to the relationships between users

  • Tags can enforce that the third-party extensions do not violate

high level policy

W2SP 2010

slide-29
SLIDE 29

29

The End

Ioannis Papagiannis DoC, Imperial College London

ip108@doc.ic.ac.uk

slide-30
SLIDE 30

30

Related Work

[How are Erlang Processes Lightweight? 2006]

  • Stack frames can be resized/moved (mem)
  • User-level, efficient caching when switching (time)
  • Lack of shared state means no locking (time)

[xBook09]

  • Uses a subset of JavaScript on the server side
  • Recreates Erlang’s communication model

[Abestos05]

  • Lightweight OS Processes, one per user
  • Cooperative Scheduling