-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dear Wine developers, I am attempting to package Wine for OLPC. My goal is to enable packaging individual windows programs into OLPC "Activity bundles" with wine. I have encountered a handful of problems along the way. One of them is bug #12507, for which I have sent a patch. A few others are:
1. Decorations on the Desktop window. I am running in Desktop mode, because this provides the best integration with the OLPC operating system. However, the desktop window has decorations on it, which I do not want. I want the desktop to be a fullscreen window. It seems that recent patches to x11drv may make this possible, but I could find no way in 0.9.59.
What should I do to run the Desktop as a full-screen window, or as a normal window without decorations?
2. Non-ownership of .wine/ The OLPC security system is designed to run each program under a different unix uid, as a form of lightweight sandboxing. My system is set up to create a .wine/ directory the first time the program is run. The second time the application is run, it doesn't work because the .wine directory is owned b a different user, so I get "path/.wine is not owned by you". I have tried doing "chmod a+rwx" to .wine/ on the first run, but Wine still refuses to run, even though it has full access, because it's not the owner.
Would you consider patches to exchange the uid check for a rwx access check?
Thank you, Ben
On Fri, Apr 11, 2008 at 5:59 PM, Benjamin M. Schwartz bmschwar@fas.harvard.edu wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dear Wine developers, I am attempting to package Wine for OLPC. My goal is to enable packaging individual windows programs into OLPC "Activity bundles" with wine. I have encountered a handful of problems along the way. One of them is bug #12507, for which I have sent a patch. A few others are:
- Decorations on the Desktop window.
I am running in Desktop mode, because this provides the best integration with the OLPC operating system. However, the desktop window has decorations on it, which I do not want. I want the desktop to be a fullscreen window. It seems that recent patches to x11drv may make this possible, but I could find no way in 0.9.59.
What should I do to run the Desktop as a full-screen window, or as a normal window without decorations?
- Non-ownership of .wine/
The OLPC security system is designed to run each program under a different unix uid, as a form of lightweight sandboxing. My system is set up to create a .wine/ directory the first time the program is run. The second time the application is run, it doesn't work because the .wine directory is owned b a different user, so I get "path/.wine is not owned by you". I have tried doing "chmod a+rwx" to .wine/ on the first run, but Wine still refuses to run, even though it has full access, because it's not the owner.
Would you consider patches to exchange the uid check for a rwx access check?
No, that check was added to keep users from running Wine as root.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
James Hawkins wrote: | On Fri, Apr 11, 2008 at 5:59 PM, Benjamin M. Schwartz |> Would you consider patches to exchange the uid check for a rwx access check? | No, that check was added to keep users from running Wine as root.
Then why not prevent users from running Wine as root? This does not prevent that.
- --Ben
On Fri, Apr 11, 2008 at 6:11 PM, Benjamin M. Schwartz bmschwar@fas.harvard.edu wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
James Hawkins wrote: | On Fri, Apr 11, 2008 at 5:59 PM, Benjamin M. Schwartz |> Would you consider patches to exchange the uid check for a rwx access check? | No, that check was added to keep users from running Wine as root.
Then why not prevent users from running Wine as root? This does not prevent that.
It prevents this case:
$ sudo wine app.exe
and we've already decided that we're not going to outright prevent users from running wine as root. There are certain circumstances where it's required.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
James Hawkins wrote: | On Fri, Apr 11, 2008 at 6:11 PM, Benjamin M. Schwartz | bmschwar@fas.harvard.edu wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> James Hawkins wrote: |> | On Fri, Apr 11, 2008 at 5:59 PM, Benjamin M. Schwartz |> |> Would you consider patches to exchange the uid check for a rwx access |> check? |> | No, that check was added to keep users from running Wine as root. |> |> Then why not prevent users from running Wine as root? This does not |> prevent that. |> | | It prevents this case: | | $ sudo wine app.exe | | and we've already decided that we're not going to outright prevent | users from running wine as root. There are certain circumstances | where it's required.
Then how about a patch that specifically prevents users from running wine as root over a profile that is not owned by root? I am trying to run wine as a non-root user over a profile owned by another non-root user that has been chmod'ed appropriately.
- --Ben
On Fri, Apr 11, 2008 at 7:45 PM, Benjamin M. Schwartz bmschwar@fas.harvard.edu wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
James Hawkins wrote: | On Fri, Apr 11, 2008 at 6:11 PM, Benjamin M. Schwartz | bmschwar@fas.harvard.edu wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> James Hawkins wrote: |> | On Fri, Apr 11, 2008 at 5:59 PM, Benjamin M. Schwartz |> |> Would you consider patches to exchange the uid check for a rwx access |> check? |> | No, that check was added to keep users from running Wine as root. |> |> Then why not prevent users from running Wine as root? This does not |> prevent that. |> | | It prevents this case: | | $ sudo wine app.exe | | and we've already decided that we're not going to outright prevent | users from running wine as root. There are certain circumstances | where it's required.
Then how about a patch that specifically prevents users from running wine as root over a profile that is not owned by root? I am trying to run wine as a non-root user over a profile owned by another non-root user that has been chmod'ed appropriately.
Running as root was just a specific example. The second case isn't allowed either.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
James Hawkins wrote: | On Fri, Apr 11, 2008 at 7:45 PM, Benjamin M. Schwartz |> Then how about a patch that specifically prevents users from running wine |> as root over a profile that is not owned by root? I am trying to run wine |> as a non-root user over a profile owned by another non-root user that has |> been chmod'ed appropriately. |> | | Running as root was just a specific example. The second case isn't | allowed either. | I appear to have hit a nerve here; "isn't allowed" is surprisingly strong language for an open source software project.
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.
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. In fact, it allows complete sandboxing of each Wine instance, isolating it from the rest of the system by kernel-level mechanisms.
I would prefer not to maintain a patched fork of Wine just to get this trivial feature. That doesn't benefit anyone. I'm sure we can find a way to provide this ability without compromising the security of users in the general case.
- --Ben
On Saturday April 12 2008 04:54:44 Benjamin M. Schwartz wrote:
I need the ability to run in profiles as a user who is not the "owner" of the files on disk. ... I would prefer not to maintain a patched fork of Wine just to get this trivial feature. That doesn't benefit anyone. I'm sure we can find a way to provide this ability without compromising the security of users in the general case.
Well, you probably want to see http://bugs.winehq.org/show_bug.cgi?id=11112 - there you find a discussion about this issue. Personally, I use attached hack for now until above bug will be FIXED.
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.)
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.)
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.
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 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?
-----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
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ove Kaaven wrote: | Benjamin M. Schwartz skrev: |> 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.
This appears to have worked. WINEPREFIX cannot be a symlink, but making it a directory with 5 symlinks in it solves the problem.
If the developers want to create a high barrier to running Wine under multiple uid's, this is not a bad balance point. Perhaps I will document it.
- --Ben
-
Benjamin M. Schwartz -
James Hawkins -
L. Rahyen -
Ove Kaaven