Difference between revisions of "Talk:Distributed OS: Winter 2011"

From Soma-notes
Jump to navigation Jump to search
 
(2 intermediate revisions by 2 users not shown)
Line 3: Line 3:


Ideas:  
Ideas:  
*Multiple control/chokepoints where malware is looked for. This way, it's more difficult for attackers to take over several control points and for malware to remain unnoticed.
 
*Heterogeneous systems help limit the spread of malware too. There's 2 points here. (1) If we're designing this system where we're all masters of our own domains, then we're likely to have different system configurations. However (2), if we want to communicate and interact with other domains, we need some standardized communication layer or mechanism. Standardization is very closely tied to homogeneous.
*There should be consequences if you harbor malware or if malware originates from within your domain. This could be and incentive to help people be more proactive in terms of security.





Latest revision as of 12:16, 9 February 2011

3: Limiting the spread of malware

Group members: keith, Andrew, David Barrera, Trevor Gelowsky

Ideas:


System Proposal (TG):

In this case, what exactly do we look for? Malware is just another piece of software, especially in an internet-scale operating system. "Attackers" are just users with malicious intent.

My idea (continuing the countries analogy) is that every piece of software would execute with a "passport" representing key information about the software executing. At this point, based on the "passport" information, domains can deny or limit the ability of software to interact. For example, if a user runs an application, then their "stamp", along with their domain "stamp" and system "stamp" would become a part of that application's passport. Any domain or system can reference the signature's origin and verify it's authenticity (think of public key encryption, but every domain/person/system has its own key server). If a part of the passport is fraudulent or unverifiable then the communication or work can be rejected. If one system becomes a source of malware, then that system, user, or domain passport "stamp" can be rejected. The more legitimate "stamps" a piece of software has, the more trusted the software may be. Every domain can decide which passport stamps to accept, and which to reject. Even if a portion of a passport is fraudulent, the fraud can be detected and the information regarding untrusted passport information can be circulated between trusted peer domains. This proposed system would inherently prevent malware from spreading, because after a piece of malware was discovered, it's passport could be rejected. A continued source of malware could also be rejected.