Code Security - PowerPoint PPT Presentation

About This Presentation
Title:

Code Security

Description:

Building a fence around your code. JVM Java Virtual Machine ... Machine1 policy. Machine2 policy. User. A. User. B. User. C. User. D. Evaluating Policy Per Level ... – PowerPoint PPT presentation

Number of Views:47
Avg rating:3.0/5.0
Slides: 50
Provided by: cetli
Category:

less

Transcript and Presenter's Notes

Title: Code Security


1
Code Security
  • Gordon College
  • Stephen Brinton

2
Virtual Machine Security
  • Building a fence around your code
  • JVM Java Virtual Machine
  • Originally developed by Sun Microsystems
  • Executes Java Bytecode
  • Execution by Interpretation (JVM) or Compilation
    (JIT)
  • Common Language Runtime
  • Developed by Microsoft
  • Executes Common Intermediate Language (CIL)
  • Verified and then run as native code on machine

3
Javas Security
  • Strongly Typed Compiler
  • Eliminate programming bugs
  • Help enforce language semantics
  • Bytecode verifier
  • Makes sure the rules of Java are followed in the
    compiled code
  • Classloader
  • Finds, loads, and defines classes (runs verifier
    on them)
  • Security Manager
  • Main interface between the system and the Java
    Code

4
Trusted vs Untrusted Code
  • Trusted
  • Java API code
  • Code loaded from the classpath
  • resides outside the sandbox
  • Untrusted
  • Code loaded from outside the classpath (usually
    from a network)
  • Confined to the sandbox
  • Java Apps (by default) live outside the sandbox
    and Java Applets are confined within the sandbox

5
Whats a Sandbox?
  • Applets run inside a sandbox
  • If you download code, it has to play within the
    JVM (Sandbox)
  • SecurityManager is called for certain
    methods, and can forbid access
  • JDK1.1 introduced the notions of code-signing and
    trusted applets

6
Sandboxes
  • How do you protect your computer bad code?
  • The solution Make untrusted code play within a
    sandbox.
  • Need for varying security policies increases
  • You assign permissions to pieces of code
  • JDK 1.1 (digital signatures) if user trusts the
    digitally signed code users could allow
    normally untrusted code to access resources
  • Enforcement Mechanism for Policy (sandbox)?
  • Security Managers

7
Java Sandbox
  • The sandbox for untrusted Java applets, for
    example, prohibits many activities, including
  • Reading or writing to the local disk
  • Making a network connection to any host, except
    the host from which the applet came
  • Creating a new process
  • Loading a new dynamic library and directly
    calling a native method

8
Java Sandbox
  • The fundamental components responsible for Java's
    sandbox are
  • Safety features built into the Java virtual
    machine (and the language)
  • The class loader architecture
  • The class file verifier
  • The security manager and the Java API

9
Creating a security manager in JDK 1.1 (that
allows reading files, but disallows writing files)
  • public class MySecurityManager extends
    java.lang.SecurityManager public void
    checkRead(String file) throws SecurityException
    // reading is allowed, so just
    returnreturnpublic void checkWrite(String
    file) throws SecurityException // writing is
    not allowed, so throw the exceptionthrow new
    SecurityException("Writing is not allowed")
  • // end MySecurityManager

10
Creating a security manager in JDK 1.1 (that
allows reading files, but only with extension
txt)
  • public class MySecurityManager2 extends
    java.lang.SecurityManager public void
    checkRead(String file) throws SecurityException
    //check the file extension to see if it ends
    in ".txt"int indexfile.lastIndexOf('.')String
    resultfile.substring(index, file.length())if(r
    esult.equalsIgnoreCase(".txt"))returnelseth
    row new SecurityException("Cannot read file
    "file)

11
Security Manager prior to JDK 1.2
  • Only way security was controlled prior to JDK 1.2
  • Advantages
  • Easy to provide a binary security model (yes, you
    can or no, you can't)
  • Methods in the SecurityManager class are called
    by the Java API there's no need for you to call
    the code at all
  • Interface of this system is constant across all
    JVM platforms one security manager can run
    everywhere
  • Additional size of a simple security manager is
    negligible
  • Security manager class loader work hand-in-hand
    to ensure neither is compromised by accident or
    an act of evil

12
Security Manager prior to JDK 1.2
  • Disadvantages
  • Control of security is in the developer's hands,
    not in a security specialist's hands
  • Not easy to provide a customizable security model
    that varies from user to user
  • Only way to change an existing policy is to
    change or subclass the existing security manager
    not all users have the capability of programming
    in Java
  • New security policies (non-system resource
    policies, for example) are difficult to implement

13
Install a SecurityManager
  • Applications dont start, by default, with a
    SecurityManager
  • You must install one, either from within the
    code, or using a command line argument

java -Djava.security.manager
14
Building a bigger and better sandbox
  • To provide greater control to user and developer
    -
  • Traditional sandbox (java.security package) was
    expanded to include
  • AccessController class
  • Muscle of the security manager enforces policy
  • Permission class
  • Policy class

15
AccessController
  • java -new -usepolicy FileApp test.txt

16
The Policytool
Policy Tool Main Window
17
The Policytool
Policy Tool Edit Entry Window
18
The Policytool
Policy Tool Add Grant Entry Window
19
.NET Framework
  • Different administrative software model
  • Fixed location (traditional)
  • Dynamic nature of software (present)
  • Dynamic downloads and execution
  • Remote execution
  • Security is essential

20
Security Models
  • Role-based security
  • Users have access to resources based on roles
  • Model used by most operating systems
  • Code access security (new with .Net)
  • Also called evidence-based security
  • Even if user is trusted - the code may not be.
  • Tackles the problem with mobile code
  • Both models are found in .Net framework

21
Code Access Securitymechanism of the CLR
  • Manages code and depends on level of trust
  • CLR will lessen and tighten its grip based on
    permission and trust level
  • Very similar to the sandbox view
  • Two aspects
  • Control the access level given to an application
    (assembly)
  • Control access to a particular resource (like a
    database)

22
.Net execution
  • Runtime framework
  • Runs both managed and unmanaged code
  • Managed - under control of runtime
  • Has access to certain features memory
    management, JIT, and security services
  • MSIL (MS intermediate language)
  • Can be compiled to native code prior to execution
  • Unmanaged - compiled for a certain system
  • Can not directly use the runtime
  • MSIL object-oriented assembly language for an
    abstract, stack-based machine

23
CILcommon intermediate language
  • .method public hidebysig instance float64
  • GetVolume() cil managed
  • // Code size 51 (0x33)
  • .maxstack 2
  • .locals init (0 float64 volume,
  • 1 float64 CS0000000300000000)
  • IL_0000 ldarg.0
  • IL_0001 ldfld float64 OOP.Apertureheight
  • IL_0006 ldarg.0
  • IL_0007 ldfld float64 OOP.Aperturewidth
  • IL_000c mul
  • IL_000d ldarg.0
  • IL_000e ldfld float64 OOP.Aperturethickness
  • IL_0013 mul
  • IL_0014 stloc.0
  • IL_0015 ldloc.0
  • IL_0016 ldc.r8 0.0
  • IL_001f bge.un.s IL_002d
  • C
  • public double GetVolume()
  • double volume heightwidththickness
  • if(volumelt0) return 0
  • return volume

object-oriented assembly language for an
abstract, stack-based machine
24
CLRcommon language runtime
25
CLRcommon language runtime
  • 3 different runtimes
  • A single CLR that runs all ASP.NET apps
  • Browsers (IE) uses a single CLR that executes all
    dowloaded controls
  • CLR used to execute commands run from the OS
    shell.

26
Verification
  • 2 Forms of verification done at runtime
  • MSIL - verified
  • Invalid - JIT compiler cannot make native exe
  • Valid - can be made into native code
  • Type safe - interacts with types through exposed
    contracts
  • Verifiable - can be proved to be type-safe
  • Assembly metadata - validated
  • Metadata - describes aspects of the code file

27
Verification
  • Integrated with the compiler
  • If code is trusted
  • skip verification and compile
  • otherwise
  • MSIL verification
  • assembly metadata verification
  • if successful verification - compile

28
Code Access Security
  • Assigns permissions to assemblies based on
    assembly evidence
  • Evidence identifies code location, etc.
  • Evidence is attached to assembly when loaded for
    execution
  • Evidence limits what program can do
  • Opt-in approach

29
Permissions
  • Authority to perform protected operations
  • Accessing files, registry, network, GUI,
    execution environment, skip verification
  • Assembly load time
  • Evidence -gt grant permissions

30
Evidence
  • Zone
  • URL
  • Hash (encrypted value)
  • Strong name - unique ID for program
  • Site
  • Application Directory
  • Publisher certificate

31
Evidence
  • ltSystem.Security.Policy.Zone version"1"gt
  • ltZonegtMyComputerlt/Zonegt
  • lt/System.Security.Policy.Zonegt
  • ltSystem.Security.Policy.Url version"1"gt
  • ltUrlgt
  • file///C/winnt/microsoft.net/framework/v1.0
    .2728/mscorlib.dll
  • lt/Urlgt
  • lt/System.Security.Policy.Urlgt
  • ltStrongName version"1"
  • Key"00000000000000000400000000000000"
  • Name"mscorlib"
  • Version"1.0.2411.0"/gt
  • ltSystem.Security.Policy.Hash version"1"gt
  • ltRawDatagt4D5A90000300000004000000FFFF0000B80000
    00000000...
  • 000000000000000000000000000000000000000000000
    0000000
  • lt/RawDatagt
  • lt/System.Security.Policy.Hashgt

32
Evidence Based Security
  • The loader discovers evidence of the origin of
    the code
  • Evidence is info about the assembly
  • Used to determine the permissions granted to an
    assembly
  • Evidence is the input to the security policy
  • Publisher Authenticode signer
  • Strong Name public keynameversion
  • Site Web site of code origin
  • URL URL of code origin
  • Zone zone of code origin
  • Extensible for new kinds of evidence (custom)

33
Security Policy
Assembly Evidence
Permissions Granted
  • Mapping

Control by administrator Policy levels
Enterprise Policy Level Machine Policy
Level User Policy Level Application
Domain Policy Level
34
Security Policy
  • Determining the set of granted permissions
  • 1. Policy levels evaluate the evidence and
    generate a set of permissions.
  • 2. Permission sets calculated for each policy
    level are intersected with each other.
  • 3. Resulting permission set is compared with
    the set of permissions the assembly declared
    necessary to run.

35
Security Policy
36
.NET Framework
  • Code groups
  • Bring together code with similar characteristics
  • Evidence
  • Information used to place code into code groups
  • where code is from (internet or intranet),
    publisher, strong name, URI from download, etc.
  • Arranged in a hierarchy
  • Permissions
  • Actions you allow each code group to perform
  • For example able to access the user interface
  • Managed by system admin. at the enterprise,
    machine and user levels

37
.NET Framework
38
.NET Framework
Condition All code, Permission Set Nothing
Condition Zone Internet, Permission Set
Internet Condition URL www.monash.edu.au,
Permission Set MonashPSet Condition Strong
Name m-Commerce, Permission Set m-CommercePSet
39
Microsoft Management Console snap-in
Condition All code, Permission Set Nothing
Condition Zone Internet, Permission Set
Internet Condition URL www.monash.edu.au,
Permission Set MonashPSet Condition Strong
Name m-Commerce, Permission Set m-CommercePSet
40
Permission Sets
  • FullTrust Allows unrestricted access to system
    resources.
  • SkipVerification Allows an assembly to skip
    verification.
  • Execution Allows code to execute.
  • Nothing No permissions. Not granting the
    permission to execute effectively stops code from
    running
  • Internet Appropriate for code coming from the
    Internet. (Limited) Code will not receive access
    to the file system or registry, but can do
    limited user interface actions as well as use the
    safe file system called Isolated Storage.

Predefined Psets - can be accessed within code.
41
Stack Walk
  • When are the permissions generated by the
    code-access security module checked?
  • To determine whether code is authorized to access
    a resource or perform an operation, the runtime's
    security system walks the call stack, comparing
    the granted permissions of each caller to the
    permission being demanded.

a protected resource may demand a stack walk
42
Stack Walk
  • When are the permissions generated by the
    code-access security module checked?
  • To determine whether code is authorized to access
    a resource or perform an operation, the runtime's
    security system walks the call stack, comparing
    the granted permissions of each caller to the
    permission being demanded.

43
Security Policy Topology
  • Multiple policy levels of administration
  • Enterprise policy distributed across
    organization
  • Machine policy for all users of a machine
  • User policy specific to logged on user
  • Effective policy is the intersection of levels

Enterprise policy
Machine1 policy
Machine2 policy
User A
User B
User C
User D
44
Evaluating Policy Per Level
  • Each Policy Level contains a set of code groups
  • Code groups are arranged in a tree
  • Every code group has a membership condition and a
    set of granted permissions
  • An assembly is mapped to one of more code groups
    based on the evidence that the assembly provides

YES
ALL CODE?
None
NO
NO
YES
Internet?
Intranet?
Local?
P1
P2
P3
45
Completing Policy Resolve
  • Matching code groups evaluated
  • Union of matching permission sets per level, this
    is the permissions allowed by this level
  • Intersection of Policy Levels produces the final
    ALLOWED permission set for the assembly
  • ALLOWED Enterprise Machine User

46
Policy Tools
  • caspol.exe
  • Console Management snap-in
  • .NET Framework 2.0 Configuration

47
Example
  • caspol.exe ld
  • look at the code groups on a machine
  • caspol.exe listgroups
  • look at the code groups on a machine (more
    compact)
  • caspol.exe resolvegroup simpleSecure.exe
  • view an assemblys code groupings (effective
    permission intersection)
  • caspol.exe resolveperm simpleSecure.exe
  • view an assemblys permissions (each code groups
    brings additional permissions)

48
.NET Framework 2.0 Configuration
49
Detail Information
  • Building a bigger sandbox
  • http//www.javaworld.com/javaworld/jw-08-1998/jw-0
    8-sandbox-p2.html
  • Security in the .NET Framework
  • http//msdn2.microsoft.com/en-us/library/fkytk30f(
    vs.80).aspx
  • Java vs. .NET Security
  • http//www.onjava.com/pub/a/onjava/2003/11/26/java
    vsdotnet.html
Write a Comment
User Comments (0)
About PowerShow.com