Talk:Distributed OS: Winter 2011: Difference between revisions
Mike Preston (talk | contribs) →End User Bandwidth Management: new section |
Mike Preston (talk | contribs) |
||
Line 11: | Line 11: | ||
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. | 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. | ||
Latest revision as of 16: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.