Notes

Outline

Title

What Are You Afraid Of? Malicious attackers Melissa Word macro virus Questionable “trusted” programs Win95 Registration Wizard Buggy programs Therac-25 User mistakes/bad interfaces  tar –cf *

LCLint [Evans, PLDI ‘96] Programmers add annotations to code Lightweight static checking detects inconsistencies (often bugs) Useful, but can’t provide code safety Requires source code, expertise and effort Too hard to prove most properties statically

Solution Space Detect bad programs Malicious code detector (virus scanners) Digital signatures Platform limits on what programs can do Operating system, firewalls, Java sandbox Naccio: alter programs before running

My Work General method for defining policies Abstract resources Platform independent System architecture for enforcing policies

Naccio Architecture

Related Work

Outline

Example Safety Policies Access constraints JDK policies Resource use limits Limit number of bytes that can be written Application-specific policies TarCustom policy Behavior-modifying policies Soft bandwidth limit

Describing Policies public class AppletSecurity extends SecurityManager {   …   public synchronized void checkRead(String file, URL base) {     if (base != null) {       if (!initACL) { initializeACLs(); }       if (readACL == null) { return; }       String realPath = null;       try {     realPath = (new  File(file)).getCanonicalPath();       } catch (IOException e) {          throw new AppletSecurityException            ("checkread.exception1", e.getMessage(), file);    … }

Problem

Safety Policy Definition Resource descriptions: abstract operational descriptions of resources (files, network, …) Platform interface: mapping between  system API and abstract resources Resource use policy: constraints on manipulating those resources

Resource Description global resource RFileSystem    openRead (file: RFile)     Called before file is opened for reading    openCreate (file: RFile)   Called before new file is created and opened for writing    openWrite (file: RFile)     Called before existing file is opened for writing    write (file: RFile, nbytes: int)           Called before nbytes are written to file    preRead (file: RFile, nbytes: int)     Called before up to nbytes are read from file    postRead (file: RFile, nbytes: int)    Called after nbytes were read from file    … // other operations for observing properties of files, deleting, etc. resource RFile    RFile (pathname: String)  Constructs object corresponding to pathname

Platform Interface The ugly part - mapping from platform system calls to resource operations For every system procedure either: Describe its effects on resources, or Pass through checking to procedures it calls. Platform determines procedures PFI must describe May describe additional methods to: Improve performance and clarity Treat system code differently (risky)

Java PFI Excerpt wrapper java.io.FileOutputStream   requires RFileMap;   state RFile rfile;   wrapper void write (byte b[])     if (rfile != null) RFileSystem.write (rfile, b.length);     %%% // original method call   … // wrappers needed for constructors, other write       // methods, close and getFD

Resource Use Policy Policy is collection of properties Properties attach checking code to resource operations

LimitBytesWritten Property stateblock TrackBytesWritten   addfield RFileSystem.bytes_written: int = 0;   precode RFileSystem.write (file: RFile, nbytes: int)     bytes_written += nbytes; property LimitBytesWritten (n: int)    requires TrackBytesWritten;    check RFileSystem.write (file: RFile, nbytes: int)      if (bytes_written > n)        violation (“Attempt to write more than ” + n + “ bytes …”);

Enforceable Policies Can enforce any policy that can be defined What can be defined depends on resource operations Resource operations depend on platform interface Any manipulation done through API calls Cannot write policies that constrain memory and CPU usage Solutions possible: insert calls

Outline

Policy Compiler Policy-enforcing system library Implementations of resource operations Perform checking described by resource use policy Rewritten Java API classes Call abstract resource operations as directed by platform interface wrappers

Implementing Resources stateblock TrackBytesWritten   addfield RFileSystem.bytes_written: int;   precode RFileSystem.write (file: RFile, nbytes: int)     bytes_written += nbytes; property LimitBytesWritten (n: int)    check RFileSystem.write (file: RFile, nbytes: int)      if (bytes_written > n) violation (“Attempt …);

Rewriting Classes

Optimizations Only implement resource operation if it: May produce a violation Modifies state used elsewhere Only wrap library method if it: Calls implemented resource operation Modifies state used meaningfully Alters behavior Simple dataflow dependency analysis Not done yet: inline methods and state to remove resource overhead

Application Transformer

What’s different for Win32? Program is Win32 executable and DLLs Platform interface describes Win32 API Policy compiler Generate DLLs instead of Java classes Application transformer Replace DLL names in import table Low-level code safety is platform-specific SFI for jumps, PFI wrappers to protect memory Scan for kernel traps Policies can be reused

Outline

Preparation Costs Policy generation Time to generate policy: 1-10 minutes Cost of storing policy Average case: ~250 KB Application transformation Basically free Integrate into byte code verifier Simple string replacements in constant pool

Performance

Policy Performance

Contributions Method for defining safety policies In terms of abstract resources Policies may be reused on different platforms General architecture for code safety Prototypes for Win32 and JavaVM Encouraging results for JavaVM Minimal preparation costs Enforces policies more efficiently than JDK

Future Work What’s left to do Implementing inlining optimizations Validating/synthesizing platform interface Multiple threads Deployment, user interface, policy authoring tools Applications of Naccio’s mechanisms Performance, debugging, behavior modification Can we protect vendors as well? Restrict what modifications can be done Trust external components Use a policy to protect copyright, distribution, etc.

Conclusion