CS111 Lecture 19 (12/3/09)

By Jessica Wang, Andrew Lumbang

CLOUD COMPUTING

Brief History

Mainframes:

Mainframes were developed in the 1960s. Some notable companies which made and sold mainframes were IBM and Fugits. Mainframes are data-intensive: a problem with mainframes was geting data to the right spot. Some positive qualities of mainframes are that they optimize data, and are very reliable. Below is a diagram of the general structure of a mainframe.

Mainframes improved as time went by, but they were still pretty expensive.

Clusters:

Were developed in the 1990s, as a cheaper alternative to mainframes, because huge mainframes were too expensive. Clusters weren't as reliable as mainframes, but the extra reliability of mainframes wasn't worth the price.

Clusters are essentially composed of linux boxes all connected on the same IP network, they can all communicate with each other across the IP network. The IP network has a speed on the order of Gb. Clusters became very popular, and nowadays most computing is done with clusters, instead of mainframes or clouds. Some notable cluster systems are Beowulf and SGE(Sun Grid Engine). One thing about clusters is that the individual boxes don't have to be the same, the machines being used in the cluster can be heterogeneous (typically x86-64)

• People have made a “single-image cluster,” where the OS is in charge
  Treated like this, where everything circled is in the single-image cluster
• Application runs up
• Cluster does not know which one its running in
• Does not know where child process is forked
• Not that popular
• Can’t optimize that well
• Really hard to add in a patch
  

Clouds

• Think of them as “clusters of clusters”
• Some problems:
  • In mainframes and clusters, there is always one in charge; however, not in clouds
  • Want to link together different organizations to solve common goal, which brings in political problems:
    • Who controls the cloud?
    • Who pays?
  • Political issues get mapped into the technical issues:

    Political Issues	Technical Issues
    Who controls the cloud?	Security
    Who pays for the cloud?	Resource management

  • Suppose too many users, who gets priority? How to swap?
• Cloud technologies:
  • Amazon EC2 (virtual machines)
  • Globos (used for research to standardize ways to talk to clusters)
• Cloud advantages over clusters/grids
  • not like getting married, just a short term commitment
  • Don’t need to spend a good million dollar, just buying needed capabilities/supply
  • Your needs can vary through time, as shown in the above graph. You can just buy more supply as needed, and don't have to buy all at once.
  • Don’t need the capital investment to start; so we save on the capital investment costs
  • Don’t have to spend so much time predicting your needs, simply pay as you go, increasing as needed. Increasing is a simple matter of flipping a switch on a machine, allowing it to connect to the cloud. This is what is called "fast-scaling"
  • Good for varying demands
• Cloud disadvantages over clusters
  • When it comes to money, it depends...its not necessarily more expensive. Its best to run the numbers between using a cloud and using a cluster to determine which is cheaper
  • Privacy: data confidentiality
    • One way to remedy this is to encrypt data going to and from the cloud, the computing part of the cloud components just be trusted
  • Network latency is a big limiting factor for the cloud.
    • "Sneakernet"-style technology, network latency was so slow that it was actually faster to store the data on on say, a DVD, and walk down the hall to transfer the data.
  • Bugs
    • As projects and programs begin to scale up, the bugs are appearing and becoming trickier to debug (hard bugs). Correctness and performance are the two most common types of bugs.  It is still an unsolved problem if we want it to solve it cheaply.  Natural conservatism is in order.
  • Other Security (not privacy)
    • Deny of Service attacks (DoS attack)
    • Physical attacks make it harder to shut down
  • Overload risks (business problem)
    • If there are a bunch of traffic in cloud, your needs can potentially go over the capacity.  Being able to “grow quickly as needed” is just an illusion.  There is also the societal risk of having a greater downside if something goes bad.  An example is how if Amazon goes down, lots of clusters would fail with it.  Often, the biggest problem is overloading of data access.  Scalable storage is another issue to consider.
    • The best way to defend yourself is to have multiple suppliers with one as a backup.
  • Vendor lock-in
    • After using a particular vendor, you might end up staying with it forever.  For example, you might not want to use ECS because you’re scared you’d be stuck with Amazon.
  • Software licensing
    • For proprietary software, ones that are neither free nor open source, if you want to run them on a cloud, you’d have to pay big bucks.  This lead to the big-bucks problem (licensing formulas).
    • For free software, even when you run it in a cloud, you aren’t allowed to distribute it due to licensing issues. 

SECURITY (continued)

Continuing from the previous lecture, we now want to get something that is simpler and easier to manage and understand.  Nevertheless, we still want the ability accurately prohibit bad accesses and allow good ones.

Techniques for doing so:
Traditional Unix

• Simple, but not too accurate

User      Group   Other
|  r w x  |  r w x  | r w x  |   

Original Unix

• user only had one group
  • users:    | . . . . | . . . . | . . . . |

Berkeley Software Distribution (BSD)

• user can have several groups
• there is no longer a simple hierarchy

***only ROOT can create groups***

Access Control Lists (ACLs)
An owner of a resource can specify an access list-a list of principles and their permissions.  Typically used in Windows NT, Solaris, Samba, and now even Unix , ACLs add more flexibility but also complexity.

Ex. On a Solaris machine

$getfacl .
user: rwx
group: r_x
other: r_x
$setfacl .                             

Key Idea:
If you correctly set the default values of ACLs, when an object or resource is created, you will not have to use setfacl too often; the properties should have been correctly inherited.  In other words, if you set root default accurately, all its inherited directories will have the same property.

Problem:
$ sudo
# cd /bad/guy
# ls

All you wanted was ability to inspect file, not to run some program. 

Role-Based Access Control (RBAC)
Only really used in big popular products (Oracle, Solaris, and Active Directory)
Grants access to roles, not to the people

Ex. If you’re in backup role, you only get backup abilities.  Also works for poweroff, change grades, etc.

RBAC has a table that tells us that for every user, which roles they can assume.  Applications run c, but have li…  However, the downside of this method is that it is too complicated and is not really used in private. 

The cube is now:

Mechanisms for Enforcing Access Control

1. ACLs: Most commonly used, ACLs associate with each object an attached inode that informs you of those who are allowed to use object.  All accesses are mediated by the OS and must ask permission from the OS before accessing it.  Through system calls, you will give the OS an ID.  The ACL is controlled by the OS.
2. Capabilities approach: Records, for each user, the list of resources that users can access.  Capabilities are unforgeable object references that points to a set of access rights.  They are almost like an inverted ACL-each principal has a set of capabilities.  Every access must be examined, therefore needing the help of the OS and hardware.  As a result, if you screw up, the OS can catch it easier.

Neither of the approaches dominates over the other since both methods ensure unforgeability and has the OS checking all accesses.  However, on a network basis, capabilities approach is preferred.  In order to gain access, you need to send your credentials (they should be encrypted) over, which is exactly what capabilities method does.   Even if you follow ALC approach, you would end up molding it to the capabilities one.

TRUSTED SOFTWARE
OS doesn’t trust users and consequently applications, which run on behalf of users.  However, some programs do need to be trusted.  One such program is login()

1. Prints “Login”                                                                                                    $ login
2. Requires name and password
3. Checks if password matches
4. login becomes user name through setuid                                                             $ setuid (10976)

Running another process as another user is not a security breach in this case because setuid is a privilege syscall that checks if caller has access to change UID-has setuid bit set.

                                            -r-sr-xr-x                                            
s: when this file starts up running, it should start as owner (root) of file.

Since we have small software we trust, which ones do we trust?

• Want to trust as few as possible
• Want them to be as small as possible
• Ex. we don’t want to trust firefox or X server since their codes are too big
  
  
  

How can we trust login?
Cryptographic checksum of the program

How does vendor trust login?
Look at login.c and confirm there are no dangerous parts

However, simply reading the source code does not a lways guarantee a working and safe program.  In his paper, “Reflections on Trusting Trust”, Ken Thompson proves how only reading code does not ensure integrity by forcing the GCC to misbehave. 

Looking at the source code, it seems perfect.  There is not anything wrong with the c files.  However, it can actually break any code.  The only way to detect the bug is to disassemble the object code itself.

Trusted Computing Base

The trusted base should be as small as possible (according to K. Thompson, it’s bigger than you think) and should be kept secure.  It contains the kernel and root.