CSE 509: Lecture Notes for 1/31/2006 Human Factors in Security: -------------------------- Unusable security is unused security. Sometimes security gets in the way, so users will circumvent it. e.g. Configuring NFS is such a hassle, that its hard to get it right in the first few attempts. With Cryptography, there have been sucesses and failures. Sucesses: SSH, SSL Failures: Email (Mozilla plugin for crypto. - Enigmail), WEP (Implementation issues. Crypto is not secure.) The general principle is that the cost to secure should be less than the cost of what you are securing. This has been in favour of Crypto in SSH (securing the password) and SSL (securing money - online transactions) and against Email. So, most email is not secret. e.g. Corporate N/W It has a firewall and a policy that it doesn't allow any outside connection to a machine in its network and it doesn't allow access to websites on internet apart from CNN. To get around this security policy, a user could install a modem on a PC that directly connects to the internet. The security is thus compromised. ---------------------------------------------| | ______ | ------- | | | -Modem---------| PC |____ | ------- |____| | ___________ | | | | ______ |___| Firewall |____ INTERNET | | | |__________| | PC |____| |____| Trend in Computer Security : Greater Sharing --------------------------------------------- Separate --> Multiprogramming Env --> RPC --> Mobile --> ? Computers like Unix IPC Code Who knows what share share CPU data --------------------- We are here today Here is an example of Good Security, but No Sharing ___________________________________________________ | | Customers Operator Computer Printer Generator | with disk | | (& donuts!) |___________________________________________________| Secure Room Running System: 1. Users give disk to operators. 2. Operator inserts disk and turns on computer. 3. Computer runs for one hour. 4. Operator gives printout to the user. 5. Operator turns off the computer. (Complete Reset) Goals of the System: 1. Confidentiality 2. Integrity 3. Availability Ways in which security could be breached: 1. User gives malicious code on disk. 2. Operator can be bribed. (No trust). 3. Operator could (by mistake) give wrong / different output. (Trusting the Operator to be honest, diligent and a robot for integrity and availability.) 4. Reading previous user's data from the memory / disk. (Lets assume / or the design is such that Poweroff is a total reset, and nothing belonging to the previous user is retained.) So confidentiality. 5. Electromagnetic attack. (Need the room to be sealed against this) 6. Stolen disk. (Need some kind of user authentication for this) The major disadvantage of this system is its Inefficiency. It seems so hard to get this simple a system work right and remain secure. Think about a bigger, more complex system. Virtual Machines : ------------------ ________________________________ ____________________ |TLB | | CPU ________ | | virtual | physical | R | W | ____ __________ | | Regs | |---- | .... ...... .. .. |---| C |---| | | |______| | |_______________________________| | A | | | | _____________ | addr | C | | Memory | | | Interrupt | | | H | | | | | Handler | | data | E |---|________| | |___________| |-----------------------------------------|___| | | | _________ | _______ | Disk | | | Priv | | |Disk |----|________| | _______ |_______| | |_____| | | | |Clock| | __________ | Printer| | |_____| | | Printer |----|________| |____________________| |_________| | | ___________ | N/W | | Network |----|________| |_________| Introduce a supervisor that limits programs A program on this system can write anywhere in the memory. So, on this system memory protection => i/o protection. Instructions: - Load / Store among Reg / Memory - Reg / Reg computation - Flush the Cache - Load / Store the IHA To include a supervisor, lets add a instruction to - Load / Store to the TLB But, a program can write out the TLB and change it to allow access to write to some memory. Hence, we need a privilege register. Privilege Register : Load TLB Yes Read TLB No for Security, Yes for Virtual Machines Load IHA Yes Read IHA No for Security, Yes for Virtual Machines We need a page-fault handler mechanism. Lets utilize Interrput Handling to handle page faults. Incase, we have a page-fault, the interrput handler jumps into the interrupt handler code which is supervisor code, the privilege bit is on. Now, there is again an issue with translation from virtual to physical which could cause another page fault. One option is to not use TLB when in privilege mode. The other option is that the TLB keeps a fixed entry for Interrput handler code. Job of the OS: Loads page of Interrupt Handler (IH) into TLB (read only) Loads addr of IH into IHA. Loads process TLB entries. Turns off the privilege bit. Jumps to the program. Now, we have memory protection !! If the kernel area (privilege area) is readable by any process, it is obviously a concern. e.g. File-systems could use memory to cache data / structure. So, keep nothing that when read is useful or don't allow reading. OS should reset the registers, clear memory pages of the process. However, with this design, we don't have availability, since nothing stops a process from running forever. So add a clock, schedular.