Exercise 1
==========

Q1. 

1.
To restrict the use of ReadFile to calling classes compiled within D1, two information have to be provided within the security policy description file:
  - the origin of the applications calling ReadFile needs to be D1 
  - the associated permission should be to "read file" (in the target directory)

For instance:

grant Codebase "file:.../D1" {
	permission java.io.Filepermission "user.home","read" ;
} ;

2. To test the correctness of the proposed solution one could:
   - check that no security exception is raised when calling ReadFile from an application 
     located in D1 and trying to access a file authorized for reading;
   - check that a  security exception is raised when calling ReadFile from an application 
     located in D1 and trying to access a file not authorized for reading;
   - check that a security exception is raised when calling ReadFile from an application 
     located outside D1.

Q2.

1. We consider the following scenario:
      C3 calls C2 calls C1 calls ReadFile, where C2, C1 and ReadFile are compiled within D1, but not C3
   In this situation the execution fails since C3 does not comply with security policy.

2. According to Java, an operatiion restricted by the security manager may occur only if *all* the callers (in the call stack) are allowed 
   to perform this operation. 

Q3. To allow *any* C2's caller to read a file a possible solution is to "enable priviledges" within C2:

   class C2 {

       public C2() {
           AccessController.doPrivileged(new PrivilegedAction() {
            public Object run() {
                C1 c1 = new C1() ;      // calls C1
		return null ; // nothing to return 
            	} 
	    }) ;
       }
    }

   Benefits: this solution is general, and easy to implement (doesn't need to update the security policy file)
   Drawback: it is potentially dangerous 
		- this security issue could stay in the code 
                - need to control the scope of the priviledged action 

Q4. Using OS-level file control accesses is a more coarse-grained solution:
      - it does not allow to distinguish between specific callers according to their origin, signature, etc. 
      - it is a process level security policy  (not thread level, e.g., intra-application)
      - it relies on a rather large Trusted Computing Base (the OS)