CS 162 Notes for April 18, 2005 Chris Willmore cs162-da Matthew Gardner cs162-ay Topic: Security and Protection The lecture stated with authorization mechanisms - To guard the gate into a system, one must keep the gatekeeper honest. - Best way to break into a system is replace the password program - can create a backdoor password to again access - can make it so any user who logs on has root access - Another form of authorization is a badge or a key - Related to this is the issue of biometrics. - A key must not but kept secret. - The catch to this is that the key must not be easily copied (ie prohibitively expensive) and must be cheap to produce. - For example, it is difficult to forge copies of credit cards, becuase of the holograms. However people now just steal blank credut cards and make fogeries from those. - To make a key difficult to copy, one can integrate specialized ciruits. Only those with huge productive and monetary resources (ie large companies and government agencies) will be able to forge these keys. - The only way to ensure the difficulty of copying the key is to have a limited issue key blank. - For example, many of the locks in Berkeley buildings have been rekeyed with certain key blanks that only the Berkeley locksmith possesses. - Keys can be stolen, but hopefully you know that it has been stolen. - Must carry keys around, which can be inconvienient. - IBM has been using card keys since the 60's. - Biometrics is going to very important in the future. - Biometrics provide both increased secuirty and convience over traditional methods. - Generally reliable. - Right now IBM is selling laptops with thumbprint readers. - Cost perhaps only 200-300 dollars. - Most likely will become the dominant means of identification in the future. - Convenient becuase no extra keys to carry around. - Can make the fingerprint reader smarter by having it measure shape, color and temperature in addition to the characteristics of the print. - No use in having a reader that can be easily fooled by using a print lifted of a drinking glass. - There are instance of readers that can be fooled by wearing a latex glove and simply pressing on the reader surface. The residue for the last finger used is enough for the reader to grant access. - Retina scans are another option. Eyes are less prone to the variations over time that fingerprints are. - Another option is to embed a chip under the skin, like the proceedure used for pets. - Microsoft introduced an external device for biometric authorization, but it was unsuccessful. - This could be due to the inconvience of using an external device. - Exhibits a huge part of making a security system effective is making it user friendly. - Biometric devices will come out onto the market. There will most certainly be problems. The only question is whether or not developers will take the time to improve the devices or simply become dissenchanted with the idea. - Once a user is authorized, you dont want someone to be able to steal your processes identity. - Example: preventing the forging of the origin of an email - Authorization Determinization: - The problem is how to determine which use can do what. - In a given system, there are users and there are entities - the system can be described as a matrix: who can do what to what - for example, a certain user has access to a certain number of files and can use certain programs - the problem for is a realistic system is there may be thousands of users and millions of files - not wise to store the whole system as a matrix becuase it would require too much room - In practice, the matrix is stored in one of two condensed ways: - access lists: a column in the matrix; given an object, a list of users who are allowed to access/manipulate it. - Example: a given file would have access list of users who have access to it. - capabilites: a row in the matrix; list of things a given user can do - This list is very long and often stores more information than is needed. - A typical a system has classes instead of keeping information for each user - Unix has three classes: yourself, your group, and the world. - A system user might might want a finer grain, but this scheme generally suffices. - there are roughly 3 main permissions: read, write, and execute - there are other permissions such as directory permission, etc. - Access Lists - Column in the permission matrix - Most filesystems have access lists. - Important issue is the over head of access lists - If the list is stored in memory the time is usually 50-100 instructions. It is much longer if the list is stored on disk and an I/O is required. - Generally, a system just checks the list on when a file is opened, not on every read and write because the overhead would be too high - The assumption is that permissions aren't changed that often. This assumption can be wrong. - If the system wanted to restrict access of a file for a user who has already opened it, the super user could kill the process or go into the process's open file table and change bits and clober pointers. - Basically an access list is a guard at a gate. It has a list of who is allowed in. - It is easy to revoke access, just remove the user from the list for a specific file. - to get a list of everything a user has access to, the system has to check the access list of every object - If you are storing a matrix in row form, it is time consuming to construct the columns and vice versa - Capabilities - A row in the permission matrix. - Lists stored as pairs with each user. - One can think of it as a key ring: a user has access to certain objects. - In some capability systems, if a process knows the name of an object, it has access to it. - Example: page table - Every entry in the page table is a capability for that page; it has the read/write/execute permission for the process. - Example: open file table - A process can only reference files through table entries. - Since everything stored as the matrix rows, it is hard to determine, given an object, which user has access to it - Sometimes hard to revoke certain capabilities - Solution: make it so a capability does not directly access an object, but have it be an indirect pointer to a table. To revoke the capabilty just zap the pointer. - Impelmentation - Make sure capabilties cant be forged. - Tagged architecture: each capability has special bits that only the system can write. The user can manipulate capabilites but not set the tag because the bits are not visible to the user. - Segregated architecture: - Capabilities are kept somewhere where the user cant acces them, like the page table and the openfile table. - Capabilty based systems: - Intel 432: in the 1980s, an interesting research project, but disastarous commercial product. - Cambridge CAP system: research project in England - IBM System/38 - Background - In the 1960s there was System/360 - The 360 was replaced with System/370 which vm system rough 1971 - IBM then created FS (Future System) with the modern design features - There was big buzz around FS, but it wasn't compatible, so was eventually dropped - Remanants of FS, which was designed for a mainframe, were used in System/38, which was intended for personal computers. - System/38 was a capability based system, very secure, fairly expensive and slow. - IBM turned this into their small business product line. - Pluses - Provides great security - Overhead is low - Negatives - Weren't compatible with pre-existing systems - Sharing can be a problem because you have to pass the capability around - Turn Key System - literally a system that you plug in, turn the key and it runs. - Usually used for a dedicated application. Today PCs are usually used instead. - Multix - People at MIT in the 60's decided that two levels of protection (root and user) was not enough. - Proposed a system with 64 levels of security - 0 is the inner most part of the kernel and 63 means your program can't access anything. - MIT put together a consortium with Bell Labs and they needed a computer manufacturer so they went with the GE 635 which would be modified into the 645. - Bell Labs bailed out and two people from Bell Labs, Thompson and Richie, created a simplified version of Multix called Unix. - When they got around to building Multix the security had 8 levels, 0 to 7 (PC's use the same scheme with levels 0 to 3). - Any executable file would have a ring number which would tell you the privelege at which it could be read, written and called. - So you could have something that could be read in ring 4, and written in ring 3 and called in ring 5. So in ring 5 you could call it but you couldn't read it and it would start executing in ring 4 but only after it checked your parameters to make sure they were legitimate. They would arrive with a ring number and so everytime your parameters were indirected through a segment it would set the privelidge of that indirection to the lowest privelidge of anything it could have modified the indirection. So you may be running in ring 5 but anything but if youre indirected through something that is writable in ring 7 then your parameters would arrive with a ring 7 label. This is what you have to do if you want to have this facility. - IBM did its own system called the TSS, Time Sharing System. - TSO came about because users wanted time sharing so people at IBM put together a really crummy system called TSO which stands for Time Sharing Option which ran users interactively in a memory partition. - IBM had millions of customers using TSO and so when TSS came out 3 or 4 years after TSO they ended up with very few installations. - Multix was ready for delivery in the early 70's and they too ended up with very few customers. - Both TSS and Multix disappeared because there weren't enough customers to make it worth supporting. - Access Enforcement - Need to make sure that you only get access to the stuff that you are supposed to get access to. - Want this module to be small and not easily broken or broken into. - Security kernel is a part of the operating system that deals with enforcing protection and security. - The more powerful the protection mechanism the larger and more complex the security kernel must be and hence the more likely it is to have bugs. - Problems - Impostors or Trojan horses - here you put in some piece of code or a program that looks like something else. - A classic case of this is somebody sets up a fake shell on the system and it records your login and password and then passes you off to the real shell. - Spoiler - can use up all the system resources and make the system crash. - Most network programs assume the possibility of overload and when they get overloaded they drop things in the dead bucket. - Ways to break into systems - If you can get on the permission list for slash dead files (df lists everything your harddrive lists as slash dead) you can get access to the physical hard drive and do what you want with it. - Fake distribution - mail your own patches before IBM mails its own patches and get them to install your version of the operating system. - Page mode buffering - with smart terminals you could send a message to someone's terminal that would be some string that would contain in it characters that controlled the buffers inside the terminal. - So you could send to the terminal a command that said store the following characters and then another command that said dump those characters back on the outgoing line. - For example you could send a message saying rm -f * and send that back. - Buffer overflow - a lot of programs get passed a string and a parameter telling it how long it is - it often doesn't check to make sure that it can deal with that long of a string. - So the buffer overflows and the string overflows onto something else such as your code. - It is not always easy to tell if someone has broken into a system and even when you do know it is almost impossible to tell what has been changed. - Usually the only way to fix it is to reload the whole operating system.