Wine on OLPC

[Ove Kaaven]

Benjamin M. Schwartz skrev:
> -----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?

Obviously you missed the point. If I have access to your .wine 
directory, then I can compromise your entire account and everything it 
owns, it doesn't matter whether it's world-writable or not. And 
similarly, you can compromise mine, it doesn't matter what permissions 
my home directory has. Any .wine can be converted into a SSH server, FTP 
server, spam proxy, whatever you fancy, as soon as someone runs Wine.

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

But in your original post, you used chmod a+rwx precisely to give 
multiple users write access to each other's .wine directories. And since 
you're apparently arguing against that trick here, I guess you're seeing 
a reason why wine disallows it.

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

For applications that need to process a file for a couple of seconds, 
sure. But Wine might run for hours or days, so in a multiuser setting, a 
lock file that locks out other users until the first user exits is not 
enough.

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

Well, you could perhaps relax the Wine checks for this special case, but 
such a patch could still not avoid "compromising the security of users 
in the general case".

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

The big reason .wine has to be owned by the right user is that the 
wineserver socket is stored there. That's what the check really 
protects. Everything else can be symlinked in, yes.