• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
RDB - Repairable Database Systems
 

RDB - Repairable Database Systems

on

  • 917 views

 

Statistics

Views

Total Views
917
Views on SlideShare
840
Embed Views
77

Actions

Likes
0
Downloads
5
Comments
0

2 Embeds 77

http://research.alexeysmirnov.name 76
http://translate.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    RDB - Repairable Database Systems RDB - Repairable Database Systems Presentation Transcript

    • A Portable Implementation Framework for Intrusion-Resilient Database Management Systems Alexey Smirnov and Tzi-cker Chiueh Department of Computer Science SUNY at Stony Brook DSN 2004
    • Outline
      • Motivation
      • System Architecture
      • Transaction Dependency Tracking
      • Database Repair Process
      • Performance Evaluation
      • Summary
    • Motivation
      • Suppose you are a DBA and you have just noticed that your database has been compromised 24 hours ago. How would you repair the database?
      • Currently, the only way to do this is to restore a database backup and manually recommit benign transactions.
      • Difficulties: (1) how to tell benign transactions from malicious; (2) the amount of data can be huge and the repair process is very error-prone.
    • Motivation
      • Ideally, an intrusion-resilient DBMS should be able to
        • Track inter-transaction dependencies;
        • Perform a selective transaction rollback.
      • We propose implementation framework called RDB that can render an off-the-self DBMS intrusion resilient without modifying its internals. RDB has two components: tracking subsystem which runs at run-time and recovery subsystem which runs offline.
    • Definition of Transaction Dependency
      • A read set of an SQL statement S is the set of rows fetched by this statement.
      • We will say that statement S 2 depends on statement S 1 if at least one row from the read set of S 2 was modified by S 1 .
      • We will say that transaction T 2 depends on transaction T 1 if at least one statement of T 2 depends on a statement from T 1 .
    • Limitations of Transaction Dependency Model
      • This definition is prone to both false positives and false negatives.
      • Example of a false positive dependency:
      7 1 300 6 2 200 5 3 100 A3 A2 A1
    • Limitations of Transaction Dependency Model
      • This definition is prone to both false positives and false negatives.
      • Example of a false positive dependency:
      T1: SET A2=5 WHERE A1<250 7 1 300 6 5 200 5 5 100 A3 A2 A1
    • Limitations of Transaction Dependency Model
      • This definition is prone to both false positives and false negatives.
      • Example of a false positive dependency:
      T1: SET A2=5 WHERE A1<250 T2: SELECT A3 WHERE A3>3 7 1 300 6 5 200 5 5 100 A3 A2 A1
    • Limitation of Transaction Dependency Model
      • Another limitation is that in general, it is impossible to determine all transaction dependencies by looking at the traffic between a client and the DB server only because part of the logic may be inside the application itself.
    • How to Track Transaction Dependencies?
      • Such a tracking mechanism should be able to intercept both read and write actions performed in the database. Possible approaches are:
    • How to Track Transaction Dependencies?
      • Such a tracking mechanism should be able to intercept both read and write actions performed in the database. Possible approaches are:
      Database log analysis – read actions are not logged;
    • How to Track Transaction Dependencies?
      • Such a tracking mechanism should be able to intercept both read and write actions performed in the database. Possible approaches are:
        • Database triggers – will miss out SELECT statements;
      Database log analysis – read actions are not logged;
    • How to Track Transaction Dependencies?
      • Such a tracking mechanism should be able to intercept both read and write actions performed in the database. Possible approaches are:
        • Database triggers – will miss out SELECT statements;
      Database log analysis – read actions are not logged;
        • Tracking proxy – will intercept SQL statements coming from the client to the server;
    • Transaction Dependency Tracking
      • RDB inserts a proxy JDBC driver between the DB server and a client that transparently intercepts all queries and results. The proxy can be either on the client side
    • Transaction Dependency Tracking
      • RDB inserts a proxy JDBC driver between the DB server and a client that transparently intercepts all queries and results. The proxy can be either on the client side
    • Transaction Dependency Tracking
      • RDB inserts a proxy JDBC driver between the DB server and a client that transparently intercepts all queries and results. The proxy can be either on the client side or on the server side.
    • Transaction Dependency Tracking
      • The following changes are made to the database at the time of its creation:
        • Table trans_dep(tr_id:INTEGER, dep_tr_ids:VARCHAR) – stores IDs of transactions that depend on transation tr_id ;
        • Table annot(tr_id:INTEGER, descr:VARCHAR) – stores annotation for transaction tr_id ;
        • A new field tr_id is added to each table. It contains the ID of last transaction that modified each row.
      • The proxy uses its own transaction IDs because there is no standard way to access internal transaction ID.
    • Transaction Dependency Tracking
      • The JDBC proxy needs to update field tr_id when the data is modified and to select it when the data is fetched. The proxy rewrites SQL statements coming from the client.
      SELECT a FROM t WHERE c SELECT a, t.tr_id FROM t WHERE c
    • Transaction Dependency Tracking
      • The JDBC proxy needs to update field tr_id when the data is modified and to select it when the data is fetched. The proxy rewrites SQL statements coming from the client.
      UPDATE t SET a=v WHERE c UPDATE t SET a=v, tr_id=curTrID WHERE c
    • Transaction Dependency Tracking
      • The JDBC proxy needs to update field tr_id when the data is modified and to select it when the data is fetched. The proxy rewrites SQL statements coming from the client.
      INSERT INTO t(a) VALUES(v) INSERT INTO t(a, tr_id) VALUES(v, curTrID)
    • Transaction Dependency Tracking
      • The JDBC proxy needs to update field tr_id when the data is modified and to select it when the data is fetched. The proxy rewrites SQL statements coming from the client.
      COMMIT INSERT INTO trans_dep(curTrID,…) COMMIT
    • Summary of the Tracking Subsystem
      • Transaction dependency tracking is implemented as a JDBC proxy driver and is therefore highly portable across different DBMSs.
      • The proxy uses a lightweight approach aimed at tracking all read actions in a database.
    • Database Repair Process
      • The database is repaired by committing compensating transactions .
      • When using RDB , the repair process consists of:
        • Database log analysis (to reconstruct complete dependency information and generate compensating transactions);
        • Dependency graph visualization;
        • Repairing the database by committing compensating transactions;
    • Database Log Analysis
      • At repair time, RDB analyses the database transaction log to build a complete dependency graph and to generate compensating transactions. Different DBMSs provide different facilities for log analysis. We have studied three DB servers:
        • PostgreSQL 7.2.2
        • Oracle 9.2.0
        • Sybase ASE 12.5
    • Database Log Analysis
      • Oracle LogMiner – translates binary log into a database view that can be queried. It contains the transaction ID, the original SQL statement and a compensating SQL statement .
      • PostgreSQL – no end-user programs or APIs for log analysis. We have implemented a plugin that provides a LogMiner-kind functionality
      • Sybase – can provide a dump of its binary transaction log. The format of this dump is partially described in Sybase manuals. We have developed a tool that parses this dump and generates compensating statements.
    • Dependency Graph Visualization
      • We used GraphViz ( AT&T)
      • The application allows the user to select an initial set of malicious transactions and computes its transitive closure. Then the result can be refined by the user to build the final set of transactions to be undone.
      • We are working on a more powerful tool that can discard certain types of dependencies.
    • Performance Evaluation
      • We used TPC-C benchmark to evaluate the run-time overhead of JDBC proxy.
      • Test database size ~ 4GB.
      • We varied the following parameters:
        • Transaction mix (read intensive and read/write intensive);
        • Connection type (local or over a network);
        • Total footprint size (effect of database cache);
    • Performance Evaluation
      • Overhead is between 6% and 13%.
    • Performance Evaluation
      • Our interpretation of these results: the overhead comes mostly from additional writes to the database and transaction log.
      • Why overhead for read-intensive transactions is less than that for read/write intensive: when there are few dependencies, the number of additional writes is also small.
      • Why overhead increases when the footprint decreases: because there are fewer disk accesses performed on behalf of the client.
    • Summary
      • We developed RDB , a portable framework that can render an off-the-shelf DBMS intrusion resilient without having access to its internals.
      • The prototype has some limitations:
        • The tracking mechanism is row-based rather than column-based. This can lead to false dependencies.
        • No support for stored procedures.
        • Many DBMS vendors provide custom extensions to SQL. Currently, only part of SQL-92 is supported.