Wine on OLPC

[Benjamin M. Schwartz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ove Kaaven wrote:
| Benjamin M. Schwartz skrev:
|> I'm particularly surprised because I cannot imagine any reasonable
|> scenario in which allowing non-root users to run in .wine/ directories
|> that they do not own is a security risk.  There is no privilege escalation
|> here; the non-root user is still required by the kernel to operate within
|> the bounds of posix permissions.
|
| That's not quite correct. If user B can run user A's installation of
| Wine, then user B can easily install some script or program that gets
| executed automatically (wineboot) the next time user A runs Wine; from
| there, user B can gain unlimited access to user A's account. (Or,
| perhaps, vice versa.)

My home directory is not world-writable.  Is yours?

|
| I think that's not really the point of the check, though. Perhaps more
| problematic is probably that if user B runs user A's Wine, then files
| written (registry included) might become owned by B, with the result
| that next time user A wants to start Wine, it can't access them. (The
| most frequent problem here is the one when user B called "root", but not
| necessarily.)

This only works if one user is root; otherwise (under any normal unix
permissions setup) multiple users do not have write access to each other's
.wine/ directories.

|
| And of course, if user A and user B happens to run Wine
| *simultaneously*, they're going to overwrite each other's files and end
| up with a broken Wine installation.

That is definitely an interesting problem, as noted in the very
comprehensive bug #11112.  The suggested solution of introducing a
lockfile does seem appropriate; it's how every other unix application
solves this problem.  In my case, I have external mechanisms to ensure
that multiple instances of wine are never running simultaneously.

|
|> I need the ability to run in profiles as a user who is not the "owner" of
|> the files on disk.  I am doing this quite specifically because, in my
|> case, this greatly _increases_ the security of the system.
|
| You have a poor understanding of Unix security if you think it's good
| that files and whatever uses them are on different accounts, and if you
| think making a (fake) Windows installation publicly accessible (and
| modifiable) by every other user on the system can possibly be called secure.

I'm afraid there is not space here to describe the Rainbow security
system.  However, I am operating in a special environment in which the
system has a single human user, and unix uid's have been repurposed to
provide software isolation.  I am not, in fact, suggesting making .wine/
publicly accessible.  I am actually using "chmod g+rwx" to make .wine/
available to a particular application, because each application has a
unique gid.  Also, Rainbow uses namespaced bindmounts in such a way that
applications not running with the gid in question cannot even determine
that this .wine/ directory exists.

See http://wiki.laptop.org/go/Rainbow

|
| I'm not sure why you even need to. If you're running Wine as a different
| user, why shouldn't that different user own its own .wine/ directory?

Rainbow works by generating a new uid every time an application is
launched.  Therefore, the second time the same human runs a wine-based
program, it runs under a different uid.  In order to provide continuity of
state, I need to be able to run in a permanent .wine/ despite having a uid
that is constantly changing.

Bug #11112 suggests that it may be possible to solve this problem using
dynamically generated symlinks.  I will try that.

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIANcjUJT6e6HFtqQRAnHdAKCUxI/2HvzfiEjloGjwkcIiZ24ZpACcDBZ+
Cq9UlZY0euM9DHwlmyusyV4=
=C/Un
-----END PGP SIGNATURE-----