Another article that makes me want Wine to run in a sandbox

[Dan Kegel-2]

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.

[James Mckenzie]

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

[Dan Kegel-2]

On Sat, Nov 7, 2009 at 3:40 PM, James McKenzie
<jjmckenzie51@...> 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

[Ben Klein]

2009/11/8 Dan Kegel <dank@...>:
> 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?

[David Gerard-2]

2009/11/8 Dan Kegel <dank@...>:

> 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.

[Ben Klein]

2009/11/8 David Gerard <dgerard@...>:
> 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 :)

[Dan Kegel-2]

On Sun, Nov 8, 2009 at 3:25 AM, Ben Klein <shacklein@...> 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.

[David Gerard-2]

2009/11/8 Dan Kegel <dank@...>:
> On Sun, Nov 8, 2009 at 3:25 AM, Ben Klein <shacklein@...> 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.

[Gert van den Berg-4]

On Sun, Nov 8, 2009 at 03:55, Dan Kegel <dank@...> wrote:
> On Sat, Nov 7, 2009 at 3:40 PM, James McKenzie
> <jjmckenzie51@...> 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