Linked by Thom Holwerda on Wed 5th Jan 2011 22:09 UTC
Thread beginning with comment 456180
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
Linked by Thom Holwerda on 05/20/13 22:43 UTC
Linked by Thom Holwerda on 05/20/13 21:50 UTC
Linked by Thom Holwerda on 05/19/13 23:15 UTC
Linked by Thom Holwerda on 05/19/13 23:11 UTC, submitted by Drumhellar
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
More News »
Sponsored Links



Member since:
2010-03-08
At least a part of malware can be blocked without knowing how a program works internally, by using a capability-based security model. If the binary blob is sandboxed, it can only do the amount of harm it has been allowed to do.
Most desktop applications, as an example, don't need full access to the user's home folder. Really, they don't. Most of the time, they use this access to open either private config files, or user-designated files. Thus, if we only allow desktop apps to access their config files and user-designated files, we just got rid of that part of malware which used this universal access to the user's home folder for privacy violation or silently deleting and corrupting files without the user knowing.
It's exactly the same tactic as preventing forkbombing by not allowing a process to fork an infinite amount of times by default. Seriously, what kind of non-system software would require that with honest intents ?
This doesn't block the "please enter your facebook password in the form below" kind of malware, though... But at least, the user is conscious of what he's doing now. Only then may user education work.
Edited 2011-01-06 13:32 UTC