Dimple Kaul

1

• Dimple Kaul
• dimple.kaul_at_vanderbilt.edu
• Vanderbilt University
• Nashville, Tennessee
• http//www.dre.vanderbilt.edu/dkaul/

2
Background of L-Store

• L-Store provides a distributed file system for
  storing arbitrary sized data objects
• Provides a flexible, distributed scalable
  storage solution
• Provides a file system interface to the data
• Upload file, Download file, Make directory,
  Remove directory, List, stat etc
• This version of L-Store has a single metadata
  server distributed storage of files
• It uses IBP protocol to store files at different
  locations

3
L-Store Installation
4
Problem Motivation

• No security feature in a L-Store Distributed file
  storage system
• Adding new feature like security is challenging
  for such type of systems
• Sharing Storing of data across geographical
  distributed locations
• Any user can upload, download, list or stat
  L-Server
• Adding this feature can affect other concerns
  adversely
• Decoupling of original functionality and the new
  requirement

5
Using Advanced specialization tools

• Securing L-store application using Aspect
  Oriented Programming (AOP) -- AspectJ
• OO provides good modularity for system core
  functionality i.e., the main business logic
• Mixing primary secondary concerns results into
  a system which is difficult to understand
  evolve resulting into tangling scattering of
  code

AOP is the methodology that facilitates
modularization of crosscutting concerns
6
Security Components

• Designed Implemented basic security for L-Store
• Focused on two main security components
• Authentication
• Data at rest -- Storage at Server and Client
• Data in motion -- Data on Network (SSL)
• Authorization (Access Control)
• IBAC Policy

7
Authentication
Security in Data in Motion
Security in Data at Rest
SSL(Data in motion)
IP Address UserId MD5 (Password Client
Salt)
Login
Validates
Login success Session Key Enc(SessionID ,
Server Key)
Stores .lstore/auth/ltfilenamegt
Creates session
Any Transaction Client IP Address Session Key
UserId
L-Store Server
L-Store Client
8
Authentication

• Data at Rest
• Session Id is encrypted and stored in file at
  client side
• Session Key expires if it is not used more than
  some fixed time
• Logout command removes the file on client side
  and entry from the memory table on server side
• L-Store supports connection per request scenario
  so we have to have Session Id to keep track of
  login
• Database is PostgreSQL with SSL enabled so it is
  considered secure
• Data in Motion
• SSL protocol for secure traversal of data
  communication between client server

9
Authorization (LACL)

• Authorization is based on Entity relation of
  various database tables
• For the proof of concept implemented
  Identification Based Access Control (IBAC) policy
  
• If a user is the owner of the directory by
  default it can upload, stat, list or download
  file. If a user is not owner of the file it
  cannot do all these operations.

Identification Based Access Control policy is a
very straightforward access control mechanism
where the owner of the resource can set Access
Control
10
Database tables in L-Store
11
Authorization (LACL) (cont..)

• A user can grant permissions to any other user to
  access file for either read or write
• L-Store server has default root user who
  maintains administrates all users, permissions
  etc
• On upload of new file or creation of directory
  its metadata information/user information is
  stored in database
• User who creates or uploads a file has all the
  file permissions
• Owner of the file /or the root user can grant
  other permission to read or write that file

12
Conclusion Future work

• Not thinking ahead of time design
  considerations Using AOSD mechanism you can add
  secondary concerns without affecting main
  business logic
• We are assuming that the metadata growth is
  minimal
• Assuming database is secure
• Some minor flaws in data at rest design
• L-Store to make more scalable by moving from meta
  data server to Chord distributed hash table
• Implementation of Authentication Authorization
  for Chord distributed hash table scenario
• Current implementation uses very basic level of
  Authentication Authorization in future we
  plan to introduce user groups policies

13
Thank you