Enforcing Security Policies using Transactional Memory Introspection Vinod Ganapathy Rutgers University Arnar BirgissonMohan Dhawan Ulfar ErlingssonLiviu

Enforcing Security Policies using Transactional Memory Introspection

Vinod GanapathyRutgers University

Arnar Birgisson Mohan Dhawan

Ulfar Erlingsson Liviu Iftode

Vinod Ganapathy Transactional Memory Introspection/IPAM'08 2

X server with multiple X clients

REMOTE

LOCAL


REMOTE

Malicious remote X client

LOCAL


REMOTE

Undesirable information flow

LOCAL


Desirable information flow

LOCAL

REMOTE


X server

X server with authorization

X client

Operation request Response

Authorization policy

Reference monitor

Allowed? YES/NO


Server

The problem

Client

Authorization policy

Reference monitor

Multiple clients

Manages resources

Likely multithreaded

Security enforcement crosscutsapplication functionality


Outline

• Enforcing authorization policies

• Problems with existing techniques

• Transactional Memory Introspection

• Implementation and experiments

• Open questions and future work


Existing enforcement interfacedispatch_request ( ) {

...perform_request ( );

}

perform_request ( ) {...

perform_access (resource);

...

perform_access’(resource’);

}


Existing enforcement interfacedispatch_request ( ) {

...perform_request ( );

}


if (allowed(principal,resource,access)){perform_access (resource);

} else { handle_auth_failure1(); }; ...if (allowed(principal,resource’,access’)){perform_access’(resource’);} else { handle_auth_failure2(); };

}


Three problems

• Violation of complete mediation

• Time-of-check to Time-of-use bugs

• Handing authorization failures


I. Incomplete mediationdispatch_request ( ) {

…perform_request ( );

}


if (allowed(principal,resource,access)){perform_access (resource);

} else { handle_auth_failure1(); }; ...if (allowed(principal,resource’,access’)){

perform_access’(resource’);} else { handle_auth_failure2(); };

}

Must guard each resource access to ensure complete mediation


I. Incomplete mediationssize_t vfs_read (struct file *file, ...) {

...if (check_permission(file, MAY_READ)) {

file->f_op->read(file, ...);}...

}

int page_cache_read (struct file *file, ...) {struct address_space *mapping =

file->f_dentry->d_inode->i_mapping;...mapping->a_ops->readpage(file, ...);

}

[Zhang et al., USENIX Security ‘02]


perform_request ( ) {...if (allowed(principal,resource,access)){

perform_access (resource);} else { handle_auth_failure1() }; ...if (allowed(principal,resource’,access’)){

perform_access’(resource’);} else { handle_auth_failure2() };

}

II. TOCTTOU bugs





}

II. TOCTTOU bugs

Similar race condition found in the Linux Security Modules framework[Zhang et al. USENIX Security ’02]

Several similar bugs recently found in popular enforcement tools: [Watson, WOOT ’07]

• GSWTK• Systrace [Provos, USENIX Security ’03]

• FreeBSD Sysjail [Johnson and Deksters ’07]


II. TOCTTOU bugs




}

Authorization check and resource access must be atomic


III. Failure handling




}

Handling authorization failures is ad hoc and error prone


III. Failure handling

• Exception-handling code accounts for a large fraction of server software – Over two-thirds of server software [IBM ’87]

– Nearly 46% on several Java benchmarks [Weimer & Necula OOPSLA’04]

• Exception-handling code itself is error-prone [Fetzer and Felber ’04]

• SecurityException most often handled erroneously [Weimer & Necula OOPSLA’04]


Summary of problems

• Violation of complete mediation– Need to identify all the resources accessed– Example: Bug in Linux Security Modules [Zhang et al.,

USENIX Security ‘02]

• Time-of-check to Time-of-use bugs– Examples: [Zhang et al., USENIX Security ‘02] [Watson,

WOOT ‘07]

• Handing authorization failures– Large fraction of server code relates to error handling

[IBM survey, ’87, Weimer and Necula, ‘04 ]

– Error-handling code is error-prone! [Fetzer & Felber ’04]

Security enforcement crosscutsapplication functionality

Our solution: TMI Decouples security enforcement

from application functionality


Outline



• Transactional Memory Introspection (TMI)– Programmer’s interface– Mechanics of TMI




Transactional memory primer

• Alternative to lock-based programming• Reason about atomic sections, not locks

• TM attempts to guarantee ACID semantics

acquire(S1.lock)acquire(S2.lock)value = S1.pop()S2.push(value)Release(S2.lock)Release(S1.lock)

transaction { value = S1.pop() S2.push(value)}


Programmer’s interface to TMIdispatch_request ( ) {

transaction [ principal ] {...perform_request ( );

}}

perform_request ( ) {...perform_access (resource);...perform_access’(resource’);

}


Programmer’s interface to TMIdispatch_request ( ) {


}}


}

Authorization manager:case (resource=R, access_type=A)

if (!allowed(principal, R, A)) then abort_txallowed(principal, resource, access)?

allowed(principal, resource’, access’)?


I. Complete mediation for freedispatch_request ( ) {


}}


}

TMI automatically invokesauthorization checks


II. TOCTTOU-freedom for freedispatch_request ( ) {


}}


}

Conflicting resource accessesautomatically abort transaction


III. Error-handling for freedispatch_request ( ) {


}}


}

Unauthorized resource accessesautomatically abort transaction


Decouples functionality and securitydispatch_request ( ) {


}}


}

Authorization manager


Outline



• Transactional Memory Introspection (TMI)– Programmer’s interface– Mechanics of TMI




TM runtime system

• The TM runtime maintains per-transaction read/write sets and detects conflicts

transaction { value = S1.pop() S2.push(value)}

val1 = S1.pop()val2 = S1.pop()S2.push(val2)S2.push(val1)

Transaction Read set Write set

Green S1.stkptr S1.stkptr

Red S1.stkptr, S2.stkptr S1.stkptr, S2.stkptr


TM runtime system

Transactionbody

Execution

Read and Write Sets

Validation

Contentionmanager

Retry

Commitlogic

Commit


Transactional Memory Introspection

Transactionbody

Execution

Read and Write Sets

Validation

Contentionmanager

Retry

Commitlogic

CommitAuthorization

Auth.checks

Auth.Manager

Success

Failure

Abort



}

Transactional Memory Introspectiondispatch_request ( ) {


}}

Present in read/write set

Accesses checkedbefore tx commits


Outline







TMI Implementation: TMI/DSTM2

• Implemented using Sun’s DSTM2

• Object-based software TM system

• TM system modified to– Trigger authorization checks on additions to

read/write set and upon transaction validation– Raise AccessDeniedException upon abort– Integrate transactional I/O libraries

• Fewer than 500 lines changed in DSTM2


Porting software to TMI/DSTM2

1. Mark transactional objects with @atomic– Also require @atomic wrappers for libraries:

java.util.HashMap, java.util.Vector

2. Reads and writes to fields of @atomic objects replaced with DSTM2 accessors

3. Place transaction{…} blocks around client requests

4. Write an authorization manager


Dealing with side-effects

• Problem:– TM provides ACID semantics to memory

updates– System calls inside transaction{…} block can

violate atomicity and isolation

• Use transactional I/O packages• Integrate with commit logic


Dealing with side-effects

Transactionbody

Execution

Read and Write Sets

Validation

Contentionmanager

Retry

2-phasecommit

CommitAuthorization

Auth.checks

Auth.Manager

Success

Failure

Abort

TX I/O


GradeSheet in TMI/DSTM2


Evaluation

• Ported four Java-based servers

• GradeSheet: A grade-management server

• FreeCS: A chat server

• WeirdX: An X window management server– Enforced a simple XACML based policy

• Tar: A tar archive service– Enforced Java stack inspection policy


Modifications needed

Server LOC Lines modified Transactions

GradeSheet 900 300 1

Tar service 5,000 < 50 1

FreeCS 22,000 860 47

WeirdX 27,000 4,800 108

Authorization managers were approximately 200 lines of code in each case


REMOTE

Example policy enforced in WeirdX

LOCAL



}

When to enforce policy?dispatch_request ( ) {


}}

allowed(principal, resource, access)?


Eager



}



}}



Lazy



}



}}



Parallel


Performance overheads of TMI

-20

-10

0

10

20

30

40

50

60

GradeSheet Tar FreeCS WeirdX

TMI/Eager

TMI/Lazy

TMI/Parallel

10x

-15.8%


Performance overheads of STM• Software transactional memory imposes a

significant overheadServer Native TMI-ported Overhead

GradeSheet 395μs 451μs 14.7%

Tar service 4.96s 15.40s 2.1x

FreeCS 321μs 3907μs 11.2x

WeirdX 0.23ms 6.40ms 26.8x

Hardware-accelerated STM will reduce runtime overheads of TM runtime systems


Outline







Hardware support for TMI

• Problem: – STM imposes high runtime overheads – Want to make TMI practical for adoption on

real-world servers

• Solution: Implementing TMI in hardware transactional memory (HTM) systems– HTM-based software as fast (or faster than)

as lock-based software.


Interaction of TMI and I/O

• Problem: I/O instructions in transactions violate atomicity and isolation

• Can deal with file and database I/O with transactional libraries

• Network I/O? Display? Other devices?

• Possible solution: Combine TMI and virtual machine introspection


A formal semantics of TMI

• Problem:– Pathological interactions of TMI with STM

implementation details

• Example: Weak-atomicity, in-place updates– With Lazy enforcement, TMI can leak

sensitive information

• Solution:– Need a formal semantics for TMI


Summary

• Transactional Memory Introspection– A new reference monitor architecture– Decouples application functionality from

security policy enforcement

• Benefits– Better guarantees on complete mediation– Freedom from TOCTTOU bugs– Better handling of authorization failures

Enforcing Security Policies using Transactional Memory Introspection

Reference: Upcoming CCS 2008 paper

Vinod GanapathyRutgers [email protected]

http://www.cs.rutgers.edu/~vinodg

Thank you!

Documents

Enforcing Security Policies using Transactional Memory Introspection Vinod Ganapathy Rutgers University Arnar BirgissonMohan Dhawan Ulfar ErlingssonLiviu