http://www.linuxinsider.com/rsstory/68566.html
The article is about users who are willing to follow bogus instructions to solve a problem (or install something).
It makes me want the average desktop to be really, really locked down... and for user-installed apps to run in a sandbox so they can't break the rest of the system.
I am looking forward to hear what the discussion at http://sandboxing.org comes up with.
Dan Kegel wrote:
http://www.linuxinsider.com/rsstory/68566.html
The article is about users who are willing to follow bogus instructions to solve a problem (or install something).
It makes me want the average desktop to be really, really locked down... and for user-installed apps to run in a sandbox so they can't break the rest of the system.
I am looking forward to hear what the discussion at http://sandboxing.org comes up with.
Dan:
You really underestimate the stupidity of people. This was pointed out in the article with detail. Folks will always try to get warez to run and they will think that Linux is 'safe' until the first time they wipe out their system by running Wine as root and then installing the warez and it does its thing. This is something that WE cannot and should not control (this is a reversal of my previous statements on running Wine as root, but folks continue to do so and we cannot really stop them from doing so.)
However, adding the sandbox idea is what Java was based upon. It continues to fail to fully meet this requirement as Java still continues to need to have physical access to devices on the hosting machine. This is not a shortcoming of Java, but a shortcoming of device emulation for real-time or near-real-time processing.
James McKenzie
On Sat, Nov 7, 2009 at 3:40 PM, James McKenzie jjmckenzie51@earthlink.net wrote:
You really underestimate the stupidity of people.
I expect that people will do utterly stupid things, there's no two ways around that, it's human nature. That being the case, I think there are still opportunities for providing a safe computing experience without compromising the user's convenience. Case in point: the sandbox used by the Chromium web browser. It provides a modicum of security without getting in the way. I can easily imagine classes of windows apps, say, games, fitting nicely into a sandboxed wine environment. Sure, getting the networking right would be a challenge, but for at least casual games, it ought to be quite doable. The key is to require no user choices -- just do the right thing by default. Then the user's level of education or computer skills don't matter. - Dan
2009/11/8 Dan Kegel dank@kegel.com:
The key is to require no user choices -- just do the right thing by default. Then the user's level of education or computer skills don't matter.
E.g., convince distros to give Wine SOCKET_RAW access using file capabilities by default?
2009/11/8 Dan Kegel dank@kegel.com:
I expect that people will do utterly stupid things, there's no two ways around that, it's human nature. That being the case, I think there are still opportunities for providing a safe computing experience without compromising the user's convenience. Case in point: the sandbox used by the Chromium web browser. It provides a modicum of security without getting in the way. I can easily imagine classes of windows apps, say, games, fitting nicely into a sandboxed wine environment. Sure, getting the networking right would be a challenge, but for at least casual games, it ought to be quite doable. The key is to require no user choices -- just do the right thing by default. Then the user's level of education or computer skills don't matter.
You'd get good sandboxing running Wine apps as another user. Main problem then is integration with the user's desktop. Doable, but a nuisance.
- d.
2009/11/8 David Gerard dgerard@gmail.com:
You'd get good sandboxing running Wine apps as another user. Main problem then is integration with the user's desktop. Doable, but a nuisance.
Not really. A separate Wine user wouldn't prevent people from running Wine as root incorrectly, and if you integrate it with the normal user's home directory, it's no longer sandboxed (or at least, no more than separated wineprefixes).
I believe the type of sandboxing being discussed includes things like preventing Win32 apps from breaking out into native calls using the infamous interrupt trick. Correct me if I'm wrong though :)
On Sun, Nov 8, 2009 at 3:25 AM, Ben Klein shacklein@gmail.com wrote:
I believe the type of sandboxing being discussed includes things like preventing Win32 apps from breaking out into native calls using the infamous interrupt trick. Correct me if I'm wrong though :)
No, I was thinking of native sandboxing, so even if they did manage to make native calls, they couldn't do any harm. Running as another uid is a fine example of a native sandboxing technique. (So, on a single user system, you could have a uid dedicated to running sandboxed apps, and it would be unable to affect the regular user's data.) This would only be useful for apps that don't need to load or save user data (probably), for example, for casual games.
2009/11/8 Dan Kegel dank@kegel.com:
On Sun, Nov 8, 2009 at 3:25 AM, Ben Klein shacklein@gmail.com wrote:
I believe the type of sandboxing being discussed includes things like preventing Win32 apps from breaking out into native calls using the infamous interrupt trick. Correct me if I'm wrong though :)
No, I was thinking of native sandboxing, so even if they did manage to make native calls, they couldn't do any harm. Running as another uid is a fine example of a native sandboxing technique. (So, on a single user system, you could have a uid dedicated to running sandboxed apps, and it would be unable to affect the regular user's data.) This would only be useful for apps that don't need to load or save user data (probably), for example, for casual games.
Yes, Unix comes with pretty good sandboxing built-in in the form of separate user names. Then one could explicity open communication channels between the Unix environment and the Wine user, rather than trying to close off open-everything.
Fairly obviously, it'll take some pretty substantial real-world need for this to get anywhere near the winehq tree! But it's an interesting idea. Imagine, successfully securiing Win32 ...
- d.
On Sun, Nov 8, 2009 at 03:55, Dan Kegel dank@kegel.com wrote:
On Sat, Nov 7, 2009 at 3:40 PM, James McKenzie jjmckenzie51@earthlink.net wrote:
You really underestimate the stupidity of people.
I expect that people will do utterly stupid things, there's no two ways around that, it's human nature. That being the case, I think there are still opportunities for providing a safe computing experience without compromising the user's convenience.
Convincing packagers to recommend (not sure if anything but clam supports this...) / have clamav as a dependency might help.... (Although it would probably help if Wine uses libclamav to scan all files before running/load even if the clamav daemon is not running and libclam is present...) (No idea what infrastructure that would require, but it sould need a way to turn it of, etc... Also not sure if that is something Wine is supposed to do...)
Gert
-
Ben Klein -
Dan Kegel -
David Gerard -
Gert van den Berg -
James McKenzie