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
• f 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

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

Denning’s Information Flow Model (DFM)

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 Zi_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:
• The security of the indirect

flow x  y caused by executing the sequence of statements

• z := x; y:=z
• automatically follows from

the security of the individual statements; that is,

• x ≤ z and z ≤ y implies x ≤ y.

(refers to security classes of x,y,z)

• Example:
• Consider the sequence (x =0
• r 1 initially)

z := o; if x= 1 then z:= 1; Indirect (xto z) y:=z, Direct z to y

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
• Policy: k ≤ y but x !≤ y
• A mechanism that always

prohibits execution of this statement will provide security.

– k = 0 or H(x) =0

• To design a mechanism that

verifies x ≤ y the relation

• nly for actual flows x  y

is considerably more difficult than designing one that verifies the relation x ≤ y for any operation that 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