Cloud Computing & Security (again)</p> </head> <body> Read the cloud PDF Written by guys at berkeley - guy who did raid About future of computers On final <h1>Lecture 19 Scribe Notes</h1> <h2>Cloud computing & Security (again)</h2> <h3>By Greg Hart and Andrew Wu</h3> ------------------------------------------------------------------------------------- <h2>Mainframes - 1960s</h2> <p>Had a bus, a PPU (peripheral processing unit): act independently and programmable a CPU </br> Expensive mainframes maybe had 2 CPUs</p> <img src="mainframe.png"/> <p>Mainframes dirty secret: getting data in and out of it</p> <p>Focused on:</p> <ul>-data-intensive</ul> <ul>-data optimization</ul> <ul>-reliability</ul> <p>Big names:</p> <ul>-IBM</ul> <ul>-Fujitsu</ul> ------------------------------------------------------------------------------------- <h2>Clusters - 1990s</h2> <p>Example of cluster:</p> <img src="cluster.png"/> <p>hooked up over network, fast speeds, each box has own disk</p> <p>Can be heterogenous, x86-64 is typical</p> <p>Single-image cluster -> OS handles everything. However, there are optimization problems, hard to patch</p> <p>Big names:</p> <ul>-SGE (Sun Grid Engine)</ul> <ul>-Beowulf</ul> ------------------------------------------------------------------------------------- <h2>Clouds ~ "clusters of clusters"</h2> <p>Political Issues</p> <ul>-Who controls the cloud?</ul> <ul>-Who pays?</ul> <p>Technical Issues</p> <ul>-Security</ul> <p>Big names</p> <ul>-AmazonEC2</ul> <ul>-Globus</ul> <p>Cloud advantages over clusters/grids</p> <ul>+ short-term commitment</ul> <ul>+ pay as you go</ul> <ul>+ can grow quickly as needed; fast scaling</ul> <img src="graph1.png"/> <p>Cloud disadvantages</p> <ul>- $ "It all depends" -- Run the numbers vs clusters</ul> <ul>- Privacy -data confientiality <ul>* encrypt data to and from the cloud</ul> </ul> <ul>- Network latency <ul>- Data transfer bottlenecks -- BIG unsolved program <ul>* archiving</ul> <ul>* sneezing" style technology</ul> </ul> <ul>- Bugs -- hard ones that crop up as you scale <ul>* unsolved problem (if solving it cheaply)</ul> </ul> <ul>- Overload risks <ul>* multiple suppliers</ul> <ul>* societal risk</ul> <ul>* overload of data access is often biggest problem</ul> </ul> <img src="graph2.png"/> <p>Additional Concerns:</p> <ul>Vendor Lock-In</ul> <ul>Software Licensing -- big bucks problem (licensing formulas) <ul>* free software</ul> </ul> <p>Clouds could be software jails</p> <p>Problem:</p> <ul>you take linux <ul>run it in a cloud <ul>don't distribute it</ul> </ul> </ul> </ul> ------------------------------------------------------------------------------------- <h2>Security again</h2> <p>Want:</p> <ul>- Simpler, easy to manage & understand</ul> <ul>- Prohibit "bad" access</ul> <ul>- Allow "good" access</ul> <ul>- Need to be accurate! </ul> <h5>Traditional Unix</h5> <ul>- ex. rwxrwxrwx</ul> <ul>user group other</ul> <h5>Original Unix</h5> <ul>- User had 1 group</ul> <h5>BSD</h5> <ul>- User has multiple groups</ul> <p>ACLs - Access Control Lists</p> <p>Owner of a resource can specify access list (list pf principals and their accesses)</p> <h5>Solaris</h5> <ul>$ getfacl</ul> <ul>user::rwx</ul> <ul>group::r-x</ul> <ul>other::r-x</ul> <p>ACL key idea: make sure default ACLs are right when a resource is created</p> <p>Mechanisms for enforcing access control</p> <ul>-ACLs, etc... each rsource has an ACL attached to it <ul>all accesses mediated by OS (syscall)</ul> </ul> <ul>-Capabilities; each principal has a set of capabilities </ul> <h4>Trusted Software</h4> <p>From an OS viewpoint, OSes don't trust appplications, because they don't trust users</br> and apps run on behalf of users</p> <p>But some programs are trusted</p> <p>i.e. "login" (how does it work?)</p> ////////////////////////// <p>setuid(10976); -- only root can do it!</p> <p>setuid program r-s r-x r-x _ root</p> <ul>'s' means make user a s owner of file</ul> <p>Which programs do we trust?</p> <ul>as few and as small as possible</ul> <p>How can we trust "login"?</p> <ul>cryptographic checksum program</ul> <p>How does vendor trust "login"?</p> <p>Reflections on Trusting Trust -K. Thompson // highly recommended reading about how login cannot be trusted</p> <p>run gdb and disassemble the code</br> gdb could have been overwritten</p> Moral of the story: You HAVE to trust somebody. Or you could just write everything yourself (remember the first lecture?) </body> </html>