The Biba model : ---------------- equivalant to the Bell Lapadala (BP) upside down for confidentiality equivalant to the Bell Lapadala (BP) for integrity example: Lets say we are a spy agency collecting info from different sources We will have information which can have different level of trust associated with them. (Integrity level) (highest trust) Double checked Reliable witness Anonymous tip (lowest trust) info simply read from the internet We associate objects & domain with integrity level as their lables Lo - integrity level of Object o Ld - integrity level of domain d Then we can say - Domain d can READ object o without loosing integrity if Ld <= Lo Domain d can WRITE object o without loosing integrity if Ld => Lo i.e. To preserve integrity - NO WRITE UP similarly, we can say To preserve security - NO WRITE DOWN * Question: Can read / write be done only at same level of trust to preserve integrity & secrecy ? Answer : Different labels are associated with integrity and security. So we can actually ensure both secrecy and integrity even when domains read / write objects with different levels of trust. implementation: --------------- Both BP and Biba can be implemented using - lables on files and processes - ACM (Access control matrix) implementation of ACM: Most of the times ACM would be a sparce matrix. Therefore it can be implemented as - ACL Store COLUMNS of ACM as linked list Store these columns as objects -Capability list Store ROWS of ACM as linked list Store these ROWS as objects Systems like ext2,ext3, Andrew File sys implement ACL rather than Capability list, since - Its easy to answer the query "who can access this object ?" with ACL (its simply the list present with this object) - Domains are fuzzy The confused Deputy -------------------- In this exercise, we will implement a system which has to work at different previleges and handle the objects according to the previlege of the domain thats using this system. problem: 1. lpr deamon at a hotel allows the customer to print jobs and bills the customers as per the num of pages printed. 2. Billing file of transactions is stored at location /var/lpr/txns. 3. The customer can look at the transactions he has done using lpr -b mytxns This command retrives the billing info of the customer logged in into file mytxns. 4. Only lpr daemon has read / write access to the file txns. Assumption: OS manages all the previleges (BP, Biba, ACM) Objective of attacker : Print for free ! Intention : write to txns instead of mytxns malicious activity by attacker/customer can be : lpr -b /var/lpr/txns Version 1: The lpr daemon has R/W access to /var/lpr/txns. Consider this case where an attacker(logged in as attacker) invokes lpr to overwrite txns file. - lpr has permissions to the attackers HOME dir as it is invoked by attacker domain. - lpr also has permissions R/W access to /var/lpr/txns. lpr OS --------------- -------------------- open ("/var/lpr/txns",R) <-----------> R/W "/var/lpr/txns" this is allowed generate attackers bill open("outfile", W) R/W $HOME (if outfile = "/var/lpr/txns", the attacker has suceeded in modifying the billing data) solution: 1. lpr must check which file is user accessible and which is not before writing as a user 2. lpr must tell OS which previlege it is trying to use Version 2: So lets modify the system so that lpr associates previlege with the user. lpr OS --------------- -------------------- call of type open (previlege, file, mode) open ("1", "/var/lpr/txns",R) <-----------> R "/var/lpr/txns" (1 is the previlege level of lpr) this is allowed generate attackers bill open(2, "outfile", W) R/W $HOME (if outfile = "/var/lpr/txns", the previlege 2 for this file allows only to read it. Hence we have defeated the attackers efforts) problem: Each application will have to manage its own security by keeping note of the previleges associated with the invoker of the call. implementation: concept: unforgeble handles application pass handle to the OS with each request. The permissions will be associated with this handle (in table indexed by handle). -Each application / process will have its own file descriptor table which will be maintained by OS. -Only way to get the file discriptor is to request OS. -Since each application has a different file desciptor table, applications cannot share it. This makes it unforgeable. -Revocation is Easy. Removing the entry indexed by the descriptor can revoke the users access to this file. (observation: * Before using file open, UNIX uses ACL * After opening the file, UNIX uses capability ) Version 3: Introducing capability in the scene: To do authentication, we will use cryptography here. let signature = sig(SecretKey, Data) Without knowledge of secretkey, one cannot get the signature for Data Application OS ------------- ---------------------- cap = open("foo",r) 1. Check if the application can read "foo" 2. Construct capability from "foo", R, Signature <-------------------- 3. return capability as a ticket for furthur access return capability read (cap) request read using the capability obtained from OS 1. Check if this capability is genuine features / bugs --------------- 1. OS does not keep track of any entry / state. It simply issues the capabilities. Therefore revocation is a big problem. 2. Applications can copy capabilities 3. Local access as well as accessing file over the network will have same mechanism. (Economy of mechanism) open("foo") Server <------------------------------------- client capability -------------------------------------> read(capability) <------------------------------------- data -------------------------------------> 4. Using capability to control sharing, we can extend this model. Revocation (some thoughts) --------------------------- Its Harder now !! Put time stamp - e.g. expiration date with capability (synchronized clk is not necessery ) problems: Fast revocation not possible clients must keep renewing permission as it expires frenquently for fast revocation: OS maintains capability black list problems: OS must maintain state forever Checking is harder now Thus, revocation is all or nothing in our case Using global file table --------------------- application OS ----------- ----- cap = open("foo",R) global file table 0 ; xyz ; R/W <--------------------------- 1 ; "foo"; R (1, signature) . . . - applications can share capability - OS can revoke capability - OS must never reuse the file descriptor id, EVEN AFTER REBOOT