Code Security Gordon College Stephen Brinton. Virtual Machine Security Building a fence around your code –JVM – Java Virtual Machine Originally developed.

  • Published on
    21-Dec-2015

  • View
    218

  • Download
    0

Transcript

  • Slide 1
  • Code Security Gordon College Stephen Brinton
  • Slide 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
  • Slide 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
  • Slide 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
  • Slide 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
  • Slide 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
  • Slide 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
  • Slide 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
  • Slide 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 return return; } public void checkWrite(String file) throws SecurityException { // writing is not allowed, so throw the exception throw new SecurityException("Writing is not allowed"); } } // end MySecurityManager
  • Slide 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 index=file.lastIndexOf('.'); String result=file.substring(index, file.length()); if(result.equalsIgnoreCase(".txt")){ return; }else{ throw new SecurityException("Cannot read file: "+file); } } }
  • Slide 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
  • Slide 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
  • Slide 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
  • Slide 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
  • Slide 15
  • AccessController java -new -usepolicy FileApp test.txt
  • Slide 16
  • The Policytool Policy Tool Main Window
  • Slide 17
  • The Policytool Policy Tool Edit Entry Window
  • Slide 18
  • The Policytool Policy Tool Add Grant Entry Window
  • Slide 19
  • .NET Framework Different administrative software model Fixed location (traditional) Dynamic nature of software (present) Dynamic downloads and execution Remote execution Security is essential
  • Slide 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
  • Slide 21
  • Code Access Security mechanism 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)
  • Slide 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
  • Slide 23
  • CIL common intermediate language C# public double GetVolume() { double volume = height*width*thickness; if(volume
  • Permissions Authority to perform protected operations Accessing files, registry, network, GUI, execution environment, skip verification Assembly load time Evidence -> grant permissions
  • Slide 30
  • Evidence Zone URL Hash (encrypted value) Strong name - unique ID for program Site Application Directory Publisher certificate
  • Slide 31 4D5A90000300000004000000FFFF0000B8000000000000... 0000000000000000000000000000000000000000000000000000">
  • Evidence MyComputer file:///C:/winnt/microsoft.net/framework/v1.0.2728/mscorlib.dll 4D5A90000300000004000000FFFF0000B8000000000000... 0000000000000000000000000000000000000000000000000000
  • Slide 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 PublisherAuthenticode signer Strong Namepublic key+name+version SiteWeb site of code origin URLURL of code origin Zonezone of code origin Extensible for new kinds of evidence (custom)
  • Slide 33
  • Security Policy Mapping {Assembly Evidence} {Permissions Granted} Control by administrator Policy levels: * Enterprise Policy Level * Machine Policy Level * User Policy Level * Application Domain Policy Level
  • Slide 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.
  • Slide 35
  • Security Policy
  • Slide 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
  • Slide 37
  • .NET Framework
  • Slide 38
  • 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
  • Slide 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
  • Slide 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.
  • Slide 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
  • Slide 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.
  • Slide 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 policyMachine2 policy User A User B User C User D
  • Slide 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 ALL CODE?None Internet?Intranet?Local?P1P2P3 YES NO YES
  • Slide 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
  • Slide 46
  • Policy Tools caspol.exe Console Management snap-in .NET Framework 2.0 Configuration
  • Slide 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)
  • Slide 48
  • .NET Framework 2.0 Configuration
  • Slide 49
  • Detail Information Building a bigger sandbox http://www.javaworld.com/javaworld/jw-08-1998/jw-08-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/javavsdotnet.html

Recommended

View more >