Enforcing Security Policies using Transactional Memory Introspection

Enforcing Security Policies using Transactional Memory Introspection

Vinod GanapathyRutgers University

Arnar Birgisson Mohan DhawanUlfar Erlingsson Liviu Iftode

Take-home slide

Vinod Ganapathy Transactional Memory Introspection

We can utilize the mechanisms ofSoftware Transactional Memory

to greatly improve security policy enforcement

Vinod Ganapathy

X server with multiple X clients

REMOTE

LOCAL

Transactional Memory Introspection

Vinod Ganapathy

REMOTE

Malicious remote X client

LOCAL


Vinod Ganapathy

REMOTE

Undesirable information flow

LOCAL


Vinod Ganapathy

Desirable information flow

LOCAL

REMOTE


Vinod Ganapathy

X server

X server with authorization

X client

Operation request Response

Authorization policy

Reference monitor

Allowed? YES/NO


Security enforcement crosscuts

application functionality

Vinod Ganapathy

Outline

• Enforcing authorization policies• Problems with existing techniques• Transactional Memory Introspection• Implementation and experiments


Vinod Ganapathy

Existing enforcement interfacedispatch_request ( ) {

...perform_request ( );

}

perform_request ( ) {...

perform_access (resource);

...

perform_access’(resource’);

}


Vinod Ganapathy

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(); };

}


Vinod Ganapathy

Three problems

• Violation of complete mediation• Time-of-check to Time-of-use bugs• Handing authorization failures


Vinod Ganapathy

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


Vinod Ganapathy

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]


Vinod Ganapathy

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


Vinod Ganapathy




}

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]

• OpenBSD Sysjail [Johnson and Deksters ’07]


Vinod Ganapathy

II. TOCTTOU bugs




}

Authorization check and resource access must be

atomic


Vinod Ganapathy

III. Failure handling




}

Handling authorization failures

is ad hoc and error prone


Vinod Ganapathy

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]


Vinod Ganapathy

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 crosscuts

application functionality

Our solution: TMI Decouples security

enforcement from application functionality


Vinod Ganapathy

Outline

• Enforcing authorization policies• Problems with existing techniques• Transactional Memory Introspection (TMI)

– Programmer’s interface– Mechanics of TMI

• Implementation and experiments


Vinod Ganapathy

Transactional memory primer

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

• TM provides atomicity and isolation

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)}


Vinod Ganapathy

Programmer’s interface to TMIdispatch_request ( ) {

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

}}

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

}


Vinod Ganapathy

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’)?


Vinod Ganapathy

I. Complete mediation for freedispatch_request ( ) {


}}


}

TMI automatically invokesauthorization checks


Vinod Ganapathy

II. TOCTTOU-freedom for freedispatch_request ( ) {


}}


}

Conflicting resource accessesautomatically abort transaction


Vinod Ganapathy

III. Error-handling for freedispatch_request ( ) {


}}


}

Unauthorized resource accessesautomatically abort transaction


Vinod Ganapathy

Decouples functionality and securitydispatch_request ( ) {


}}


}

Authorization manager


Vinod Ganapathy

Outline

• Enforcing authorization policies• Problems with existing techniques• Transactional Memory Introspection (TMI)

– Programmer’s interface– Mechanics of TMI

• Implementation and experiments


Vinod Ganapathy

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


Vinod Ganapathy

TM runtime system

Transactionbody

Execution

Read and Write Sets

Validation

Contentionmanager

Retry

Commitlogic

Commit


Vinod Ganapathy


Transactionbody

Execution

Read and Write Sets

Validation

Contentionmanager

Retry

Commitlogic

CommitAuthorization

Auth.checks

Auth.Manager

Success

Failure

Abort


Vinod Ganapathy


}

Transactional Memory Introspectiondispatch_request ( ) {


}}

Present in read/write set

Accesses checkedbefore tx commits


Vinod Ganapathy

Outline

• Enforcing authorization policies• Problems with existing techniques• Transactional Memory Introspection• Implementation and experiments


Vinod Ganapathy

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


Vinod Ganapathy

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


Vinod Ganapathy

GradeSheet in TMI/DSTM2


Vinod Ganapathy

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


Vinod Ganapathy

Modifications needed

Server LOC Lines modified Transactions

GradeSheet 900 300 1

Tar service 5,000 < 50 1

FreeCS 22,000 860 47WeirdX 27,000 4,800 108

Authorization managers were approximately 200 lines of code in each case


Vinod Ganapathy


}

When to enforce policy?dispatch_request ( ) {


}}

allowed(principal, resource, access)?


Eager


Vinod Ganapathy


}



}}



Lazy


Vinod Ganapathy


}



}}



Parallel


Vinod Ganapathy

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%


Vinod Ganapathy

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 TMs reduce runtime overheads of TM runtime systems


Take-home message

Vinod Ganapathy Transactional Memory Introspection

We can utilize the mechanisms ofSoftware Transactional Memory

to greatly improve security policy enforcement

Vinod GanapathyRutgers University

[email protected]

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

Thank you!Reference:

Enforcing Authorization Policies using Transactional Memory Introspection

Proc. ACM CCS, October 2008

Documents

Enforcing Security Policies using Transactional Memory Introspection