Language-Based Access Control and Safety Language-based access - PowerPoint PPT Presentation

Language-Based Access Control and Safety • Language-based access control is impossible in a programming language that is not memory safe. Without memory safety, there is no way to guarantee separation of memory used by different program components • Is it possible for one to achieve language-based access control without type safety • (Figure: ) code in component A should be prevented from accessing data belonging to component B. • Stronger still, it should be prevented from accessing data of the underlying language platform since any data used in enforcing the access control by the language platform could be corrupted 1

2

Realizing Language Based Access Control • Requires policies to specify access rights, a policy language to express, and a mechanism to enforce them. • Sandboxing – policies to assign permissions to components – Code source – directory, or Internet or communicated • Stack Walking: – Method invokation – complicates the interpretation of policies – Thread T tries to access resource, access is only permitted if all components on call stack have the right to access it • One major Issue: Alias Control of mutable objects 3

Code-based versus process-based access control • Language-based access control : – Based on origin of the code and the associated visibility restrictions • OS: based on the process identity 4

Security via Information Flow Control • IFC - a more expressive category of security properties than traditionally used in access control. • It is more expressive than access control at the level of the operating system or at the level of the programming • Information Flow does take into account what you are allowed to do with data that you have read, and where this information is allowed to flow – For write access, it not only controls which locations you can write to, but also controls where the value that you write might have come from. 5

An Example • APP: First locate the nearest hotel say using Google maps, and then book a room there via the hotel's website with his credit card. – Location data will have to be given to Google, to let it find the nearest hotel. – The credit card information will have to be given to the hotel to book a room. • These should be the policy of the APP 6

Decentralization and Declassification • Password Example • Vickery Auction • EasyChair Conference System • Confused Deputy Problem 7

Password Example • Endorse (guess, new_password); • if declassify(password= guess) then result= success else result=failure 8

Language Based Security in Practice • Type Safety -- tools • Source code analysis tools: perform some form of IFC • Source code scanning tools: analyse code at compile time to look for possible security flaws. – simplest versions just do a simple syntactic check to look for dangerous expressions, – Deeper analysis: Flow analysis 9

Language Based Security in Practice • Deeper Analysis: IFC – Focus on integrity rather than confidentiality. – Check for tainting: arguments of HTTP POST or GET requests in web applications – • tool will try to trace how tainted data is passed through the application and flag a warning if tainted data ends up in dangerous places • for example, arguments to SQL commands without passing through input validation routines. – Tool has to know which routines should be treated as input validation routines (take tainted data as input and produce untainted data) • Dynamic tainting 10

Run Time Monitoring • Enforcing IFC - Harder • Flow properties are harder to enforce by run- time monitoring than access control • Run Time Monitoring through RWFM Model • Static Certification – JIF Status – Certifying Python Programs ( Abhishek Singh, MTECH Thesis, 2016) via RWFM 11

Denning’s Information Flow Model (DFM) DFM = (S,O, SC, ≤, ⊕ ) S • S is a set of subjects /principals (active agents responsible for all info. flow), • O is a set of objects (info. containers), • SC is a set of security classes , • ≤ is a binary relation on security classes that specifies permissible info. flows . • sc1 ≤ sc2 means: info. in security class sc1 is allowed/permitted to flow into security class sc2, • ⊕ is the class-combining binary operator (assoc. & comm.) that specifies, for any pair of operand classes, the class in which the result of any binary function on values from the operand classes belongs 12

13

14

Security of Flows • A system enforcing Denning’s flow model DFM is secure if and only if execution of any sequence of operations of the system cannot give rise to a flow that violates the permissible information flow relation. • Further, the natural conditions required of information flow force the structure (SC, ≤) to be a lattice with ⊕ as the least upper bound operator 15

Flow Policy: Lattice Structure

Subset lattice

Transformation of nonlattice policy into a lattice • Take an arbitrary flow policy P = (SC, ≤) and transform it into a lattice P' = (SC', ≤’); • classes A and B in SC have corresponding classes A' and B' in SC' such that A ≤ B in P if and only if A’ ≤’ B' in P‘ • Flow is authorized under P if and only if it is authorized under P', where objects bound to class A in P are bound to class A' in P'. – Requires only that the relation ≤ be reflexive and transitive . – To derive a relation ≤’ that is also antisymmetric, classes forming cycles are compressed into single classes. – To provide least upper and greatest lower bound operators, new classes are added.

Example

Flow Properties Transitivity of the relation ≤ implies any indirect flow x  y resulting from a sequence of flows X = Z 0  Z 1 . . .  Zn_ 1  Zn = y is permitted if each flow Z i_1  Zi (1 ≤ i ≤ n) is permitted, because • x = z0 ≤ Z ≤ ... ≤ Zn-1 ≤ Zn = y implies x ≤ y (here reference is to security classes of the variables/objects) • Thus: an enforcement mechanism need only verify direct flows.

Examples • Example: • Example: • The security of the indirect • Consider the sequence (x =0 flow x  y caused by or 1 initially) executing the sequence of z := o; statements if x= 1 then z:= 1; Indirect • z := x; y:=z (xto z) • automatically follows from y:=z, Direct the security of the z to y individual statements; that is, • x ≤ z and z ≤ y implies x ≤ y. (refers to security classes of x,y,z)

Examples • To verify the security of an assignment statement: y := x1 + x2 * x3 • a compiler can form the  class x = x1 x2 x3   • Verify x y

Examples • To verify the security of an if statement if x then begin Y1:= O; Y2 := O; Y3 := 0 End • Form y1 y2 y3   • verify the implicit flows x  yi (i = 1, 2, 3)  by checking x y

Examples • X := 1 • X:=x+1 • x := 'On a clear disk you can seek forever‘ Is always authorized Because • Low is an identity on the class of the  expression • "x + 1" is simply x Low = x. 

Security and Precision • F be the set of all possible flows in an information flow system, • P be the subset of F authorized by a given flow policy, • E be the subset of F "executable“ given the flow control mechanisms in operation.  • The system is secure if E P; – that is, all executable flows are authorized. • A secure system is precise if E = P; – that is, all authorized flows are executable.

Enforcements Example • Y:= k* x • To design a mechanism that verifies x ≤ y the relation • Policy: k ≤ y but x !≤ y only for actual flows x  y • A mechanism that always is considerably more prohibits execution of this difficult than designing one statement will provide that verifies the relation security. x ≤ y for any operation that – k = 0 or H(x) =0 can potentially cause a flow x  y

Un-decidability • Showing whether a system is secure or precise • if f(n) halts then y := x else y := 0 where f is an arbitrary function and x !≤ y • it is theoretically impossible to construct a mechanism that is both secure and precise