I have had a look at dlls/advapi/services.c and found that it is pretty incomplete. Can anybody tell what the current implementation is used for (are there any known programs starting services?) In particular I'd like to know what people generally think about the usefulness of Services in Wine. The fact that wine cannot change user personalities and is lacking most of the NT security concepts makes services pretty useless. However it may be desirable to translate services into something useful on Unix, especially for winelib (it would be useful for the app I am trying to port). Has there been a discussion yet how to set this up without compromising system security? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
On October 22, 2002 12:24 pm, Martin Wilck wrote:
The fact that wine cannot change user personalities and is lacking most of the NT security concepts makes services pretty useless.
I was thinking, can't we somehow use stuff like sudo(8) to accomplish that? I personally haven't used sudo(8), but if we do support services, we have to integrate nicely with the Unix world, IMO. -- Dimi.
On Thursday 24 October 2002 12:30 am, Dimitrie O. Paun wrote:
On October 22, 2002 12:24 pm, Martin Wilck wrote:
The fact that wine cannot change user personalities and is lacking most of the NT security concepts makes services pretty useless.
I was thinking, can't we somehow use stuff like sudo(8) to accomplish that? I personally haven't used sudo(8), but if we do support services, we have to integrate nicely with the Unix world, IMO.
A system administrator already could do this. Anyhow there's really no need to bring sudo into the picture. If a sysadmin is crazy enough to want to run a wine "service" as root, they could just invoke their executable from an init script; that's more "service" like anyhow. OTOH, I guess sudo could be used like this: if we are going to go the route of "being uncompromisingly unixey" then the services API should just manipulate init scripts. So, for example: Installing a service == create an init script Set service as "automatic" == put the script in the default runlevel Uninstall a service == remove from all runlevels & remove init script ... etc. Now, we create "wineservices.exe", create sudo permissions on this for the appropriate users, and implment it very, very carefully. Needless to say, this is a very sketchy proposition. It is "correct," from a certain perspective; it's also very, very likely that people will use it to create huge gaping security holes in their system, like basically allowing themselves to run arbitrary scripts as root with very little effort, and then, inevitably, wine will get a bad rap as a result. I'm starting to lean towards the opinion that if these security and identity aspects start to be implemented, then wine should just have its own user database, kind of like samba. So, for example, we create a database that maps unix users onto wine users, with flexible percieved windows permissions within the wine sandbox, or, in server environments, wine maps unix accounts onto domain accounts from the server. This way, a user could "be administrator" within wine, but not be root on their unix box. If we just thunk wine security down to unix security, we are ignoring a very important difference between Windows and UNIX: the vast majority of unix users don't run as root; whereas the majority of Windows users /do/ run as Administrator or some equivalent. An example: wine users need to run installers. Installers, as often as not, need Administrator permissions. This isn't an issue right now because wine ignores security and tends to look like Windows 98 or lower, anyhow. As we move towards a 2000/XP-like implementation (this is inevitable and unavoidable IMO if we want wine to remain useful), things start to get really awkward. So, User X wants to run Adobe Acrobat installer (which more-or-less works with wine right now). But it's the future, and wine looks like W2K. So when the installer gets to the stuff about installing printer drivers, it fails, forcing the user to become root to do the install. But root doesn't even have a ~/.wine directory! And if the user creates a symlink, all hell breaks loose because fake_windows becomes a mix of files owned by root and files owned by the user. I could concoct tons of similar examples. But I'll spare you the bandwidth. In short: wine has relied on unix security historically, and it's been good enough, because wine security / permissions implementations have been nonexistant or exceedingly simple. Once we start getting more sophisticated about W32 security (and it seems to me, based on recent discussion, that this time is coming sooner than later), it's going to be inappropriate to continue with this approach, because we don't want to encourage users to do wine stuff as root. -- gmt "Oh, and of course, the fastest way to dig a tunnel is to dig at both sides." -- The Linux Advanced Routing HOWTO
I think Wine should, and CAN, do without privelege escalation at all. Let's look at some of the examples presented here. If we want to give a multi user Windows experience that is compatible with the multi-user Unix experience, our trust model must be comperable. My view of such a case is this: Wine is installed on the system. This means that there is a directory called "/usr/wine", inside of which you can find "/usr/wine/windows", "/usr/wine/Program Files" etc. Permissions on this directory are set according to the unix standard - i.e. - only admins. Then again (assuming W2K compatibility) - you get "/usr/wine/Documents and Settings/dimi", that is a symlink to "/home/dimi/wine". It goes without saying that, as far as the Windows applications, "C:\Documents and Settings\dimi" is the directory, writable to the proper user. Now, you need to be administrator to install a new program. Nothing new about that. If the admin want's to change that, she can set a group to the entire /usr/wine directory structure, and give that group write permission. There are still some security issues with this model. The wine server probably needs to be SUID to server everyone, etc. But still, that is a model that works. Besides, the server does not need to be SUID root, it can have a special user for that purpose. This is probably also required for registry access, if we want to enforce registry ACLs - we can't have a malicious user by pass the wine permissions by simply accessing the file directly, so the system registry file must not be readable by normal users (hence the need for suid on the server). As for printer drivers, and services at large - there is a major question here of whether we wish Wine services to be able to server non-wine processes. If the answer is "yes", as is probably the case with an Adobe PDF printer driver, or with a winmodem's driver, root must install them. If the answer is "no", then there is no breaking of the model. With the directory structure as defined today, each user can install it, claiming full admin rights over the loca directory structure. Of course, the new adobe's printer driver only serves his programs. There is one problem with this model that has to do with windows programs that require admin in order to RUN. I know of a few of those. Some of them simply require DirectX, and these don't seem like a problem in Wine. Others require file access, and I was considering writing a program for Windows that will work around that by API remapping. I think it will be possible to make these programs work without breaking permissions. If so, it will certanly be easier to implement in Wine than in Windows. Shachar Greg Turner wrote:
On Thursday 24 October 2002 12:30 am, Dimitrie O. Paun wrote:
On October 22, 2002 12:24 pm, Martin Wilck wrote:
The fact that wine cannot change user personalities and is lacking most of the NT security concepts makes services pretty useless.
I was thinking, can't we somehow use stuff like sudo(8) to accomplish that? I personally haven't used sudo(8), but if we do support services, we have to integrate nicely with the Unix world, IMO.
Actually, I think PAM is a more apropriate answer to this. I am saying this without thorough knowledge of PAM, though.
A system administrator already could do this. Anyhow there's really no need to bring sudo into the picture. If a sysadmin is crazy enough to want to run a wine "service" as root, they could just invoke their executable from an init script; that's more "service" like anyhow.
OTOH, I guess sudo could be used like this: if we are going to go the route of "being uncompromisingly unixey" then the services API should just manipulate init scripts. So, for example:
Installing a service == create an init script Set service as "automatic" == put the script in the default runlevel Uninstall a service == remove from all runlevels & remove init script ... etc.
Now, we create "wineservices.exe", create sudo permissions on this for the appropriate users, and implment it very, very carefully.
Needless to say, this is a very sketchy proposition. It is "correct," from a certain perspective; it's also very, very likely that people will use it to create huge gaping security holes in their system, like basically allowing themselves to run arbitrary scripts as root with very little effort, and then, inevitably, wine will get a bad rap as a result.
I'm starting to lean towards the opinion that if these security and identity aspects start to be implemented, then wine should just have its own user database, kind of like samba. So, for example, we create a database that maps unix users onto wine users, with flexible percieved windows permissions within the wine sandbox, or, in server environments, wine maps unix accounts onto domain accounts from the server.
This way, a user could "be administrator" within wine, but not be root on their unix box. If we just thunk wine security down to unix security, we are ignoring a very important difference between Windows and UNIX: the vast majority of unix users don't run as root; whereas the majority of Windows users /do/ run as Administrator or some equivalent.
An example: wine users need to run installers. Installers, as often as not, need Administrator permissions. This isn't an issue right now because wine ignores security and tends to look like Windows 98 or lower, anyhow. As we move towards a 2000/XP-like implementation (this is inevitable and unavoidable IMO if we want wine to remain useful), things start to get really awkward. So, User X wants to run Adobe Acrobat installer (which more-or-less works with wine right now). But it's the future, and wine looks like W2K. So when the installer gets to the stuff about installing printer drivers, it fails, forcing the user to become root to do the install. But root doesn't even have a ~/.wine directory! And if the user creates a symlink, all hell breaks loose because fake_windows becomes a mix of files owned by root and files owned by the user. I could concoct tons of similar examples. But I'll spare you the bandwidth.
In short: wine has relied on unix security historically, and it's been good enough, because wine security / permissions implementations have been nonexistant or exceedingly simple. Once we start getting more sophisticated about W32 security (and it seems to me, based on recent discussion, that this time is coming sooner than later), it's going to be inappropriate to continue with this approach, because we don't want to encourage users to do wine stuff as root.
Dear Shachar, Thanks for this clean and convincing model.
As for printer drivers, and services at large - there is a major question here of whether we wish Wine services to be able to server non-wine processes. If the answer is "yes", as is probably the case with an Adobe PDF printer driver, or with a winmodem's driver, root must install them.
You mean Administrator here, right? I still think Administrator != root. If e.g. CUPS passes PDF data to a wine printer driver acting as a filter, I don't see why this filter would need to run as root. The winmodem is different because it requires hardware access.
If the answer is "no", then there is no breaking of the model. With the directory structure as defined today, each user can install it, claiming full admin rights over the loca directory structure. Of course, the new adobe's printer driver only serves his programs.
Yes, both approaches can actually coexist on the same machine. Great! Now someone just needs to start implementing security handling in Wine... Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Martin Wilck wrote:
Dear Shachar,
As for printer drivers, and services at large - there is a major question here of whether we wish Wine services to be able to server non-wine processes. If the answer is "yes", as is probably the case with an Adobe PDF printer driver, or with a winmodem's driver, root must install them.
You mean Administrator here, right? I still think Administrator != root.
I totally agree that Administrator does not necessarily means root. I did, however, mean root.
If e.g. CUPS passes PDF data to a wine printer driver acting as a filter, I don't see why this filter would need to run as root.
The filter does not, but installing it for all users does. This is not different from any other CUPS filter. If you don't have root, you cannot install a (unix) system wide printer. If you have administrator, you can install a printer driver that will be available to all Wine programs, but that's it. Actually, thinking about it again, I think a better approach to the printer drivers problem would be to create a CUPS filter that directs printing to the pritner driver installed in the system wide Wine. This way, it can be installed independantly of the actual windows printer drivers. Like you said in another email, however, this is somewhat in the future.
The winmodem is different because it requires hardware access.
Yes, it is. Like I said earlier, however, I would like to differentiate between requiring root to install and requiring root to run.
If the answer is "no", then there is no breaking of the model. With the directory structure as defined today, each user can install it, claiming full admin rights over the loca directory structure. Of course, the new adobe's printer driver only serves his programs.
Yes, both approaches can actually coexist on the same machine. Great! Now someone just needs to start implementing security handling in Wine...
I think implementing "multi-user" wine should come earlier. At first, you will simply get the security handling of trying to open a file and getting "access denied" from the unix permissions system.
Martin
Shachar
This thread has immediately jumped to the future-development discussion :-) In the first place, I simply wanted to know what the current rudimentary "service" implementation (which simply calls CreateProcess) is good for, and whether anybody knows about Windows or Winelib programs running on Wine that actually use this API. I think this simple approach could take us quite far without even thinking about changing user accounts, acquiring extra Unix capabilities, etc.
A system administrator already could do this. Anyhow there's really no need to bring sudo into the picture. If a sysadmin is crazy enough to want to run a wine "service" as root,
Wine shouldn't run as root. I don't see strong arguments against running a wine service in a dedicated non-root Unix user account, though.
they could just invoke their executable from an init script; that's more "service" like anyhow.
That has nothing to do with the Windows service API and won't help you a bit trying to port a Windows app that uses that API.
OTOH, I guess sudo could be used like this: if we are going to go the route of "being uncompromisingly unixey" then the services API should just manipulate init scripts.
IMO a bad idea, this comes down to real root access for wine. I'd rather install a single init script starting a daemon that - changes uid/gid to a dedicated unix account with non-root privileges, - (perhaps) does a chroot(), - starts wine. The wine process would then start all registered Windows services in his environment. An "autostart" service would mean that the process is started when the first wine process starts. To stop the services, we'd need a "shutdown" application of some sort. Obviously this would require wineserver calls, no idea if a server protocol extension would be necessary. Controlling these services would require a su(1) to the service account and starting a windows service-control executable.
This way, a user could "be administrator" within wine, but not be root on their unix box.
If you think about it, this is exactly the situation that we have now, and it's not so bad after all. No restrictions in the Win environment, but normal user privileges from the Unix perspective.
And if the user creates a symlink, all hell breaks loose because fake_windows becomes a mix of files owned by root and files owned by the user. I could concoct tons of similar examples. But I'll spare you the bandwidth.
This could be solved by a system-wide wine installation with its own security handling. All installed files would (in the Unix sense) belong to the user the wine process is running as. For very good reasons that user shouldn't be root.
Once we start getting more sophisticated about W32 security (and it seems to me, based on recent discussion, that this time is coming sooner than later), it's going to be inappropriate to continue with this approach, because we don't want to encourage users to do wine stuff as root.
I can't follow you here - **wine must not be run as root**, and we can't do anything but repeat that over and over again, whether or not we implement services and/or security management in wine. In any case, if a future wine did its own security management, the users and groups must still map to Unix users and groups - if not, how would such a future wine determine the access rights of a Unix file that only shows Unix user/group permissions? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
--- Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> wrote:
This thread has immediately jumped to the future-development discussion :-)
In the first place, I simply wanted to know what the current rudimentary "service" implementation (which simply calls CreateProcess) is good for, and whether anybody knows about Windows or Winelib programs running on Wine that actually use this API.
I think this simple approach could take us quite far without even thinking about changing user accounts, acquiring extra Unix capabilities, etc.
I have to agree with Martin here.
A system administrator already could do this. Anyhow there's really no need to bring sudo into the picture. If a sysadmin is crazy enough to want to run a wine "service" as root,
Wine shouldn't run as root. I don't see strong arguments against running a wine service in a dedicated non-root Unix user account, though.
Never, never, never, never, never run wine as root!!
they could just invoke their executable from an init script; that's more "service" like anyhow.
I would say the best way to see what this is like (in case you dot understand) would be to look at postgresql. It runs as user postgresql no matter who you are logged in as, and that user/group has only the ability to do what postgresql needs to do, nothing more nothing less, so there is very little/no threat of a compromise there.
That has nothing to do with the Windows service API and won't help you a bit trying to port a Windows app that uses that API.
OTOH, I guess sudo could be used like this: if we are going to go the route of "being uncompromisingly unixey" then the services API should just manipulate init scripts.
IMO a bad idea, this comes down to real root access for wine. I'd rather install a single init script starting a daemon that
- changes uid/gid to a dedicated unix account with non-root privileges, - (perhaps) does a chroot(), - starts wine.
The wine process would then start all registered Windows services in his environment. An "autostart" service would mean that the process is started when the first wine process starts. To stop the services, we'd need a "shutdown" application of some sort.
I totally agree with this approach. That way, you can be logged in as whoever you want to be logged in as, and if you wanted to run say word, then it would be run with uid/gid wine and therefore any files you save would only be able to do things on the wine account. Another potential problem popped into my head though, and that is: what if someone edits the initscript to where wine runs as root (or someone compromises the server and does it), or what if someone just changes the owner/group on the file (like a word doc), and then tries to run it with wine, what happens then? (all of this see below, this pertains to both this section) (and)
Obviously this would require wineserver calls, no idea if a server protocol extension would be necessary.
Controlling these services would require a su(1) to the service account and starting a windows service-control executable.
This way, a user could "be administrator" within wine, but not be root on their unix box.
If you think about it, this is exactly the situation that we have now, and it's not so bad after all. No restrictions in the Win environment, but normal user privileges from the Unix perspective.
And if the user creates a symlink, all hell breaks loose because fake_windows becomes a mix of files owned by root and files owned by the user. I could concoct tons of similar examples. But I'll spare you the bandwidth.
This could be solved by a system-wide wine installation with its own security handling. All installed files would (in the Unix sense) belong to the user the wine process is running as. For very good reasons that user shouldn't be root.
(the one above here)
Once we start getting more sophisticated about W32 security (and it seems to me, based on recent discussion, that this time is coming sooner than later), it's going to be inappropriate to continue with this approach, because we don't want to encourage users to do wine stuff as root.
I can't follow you here - **wine must not be run as root**, and we can't do anything but repeat that over and over again, whether or not we implement services and/or security management in wine.
In any case, if a future wine did its own security management, the users and groups must still map to Unix users and groups - if not, how would such a future wine determine the access rights of a Unix file that only shows Unix user/group permissions?
Martin
__________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
Am Don, 2002-10-24 um 15.43 schrieb Dustin Navea:
Another potential problem popped into my head though, and that is:
what if someone edits the initscript to where wine runs as root (or someone compromises the server and does it),
If the system is already compromised it is too late anyway. Some intruder who can change init scripts already has root rights and probably wouldn't bother with wine. If sysadmin himself changes the init script to run wine as root it is his own fault (he could as well have their apache or bind run as root, also a bad idea for both).
or what if someone just changes the owner/group on the file (like a word doc), and then tries to run it with wine, what happens then?
Unless wine has some suid capabilities (which it shouldn't) this has no impact - wine runs in the account of the user who opens the file (runs word). Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
--- Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> wrote:
Am Don, 2002-10-24 um 15.43 schrieb Dustin Navea:
Another potential problem popped into my head though, and that is:
what if someone edits the initscript to where wine runs as root (or someone compromises the server and does it),
If the system is already compromised it is too late anyway. Some intruder who can change init scripts already has root rights and probably wouldn't bother with wine.
They may do it anyways so that they have a 2nd way in (for after the original security hole is closed)
If sysadmin himself changes the init script to run wine as root it is his own fault (he could as well have their apache or bind run as root, also a bad idea for both).
True.
or what if someone just changes the owner/group on the file (like a word doc), and then tries to run it with wine, what happens then?
Unless wine has some suid capabilities (which it shouldn't) this has no impact - wine runs in the account of the user who opens the file (runs word).
I was actually thinking more from a read the file standpoint, i.e if in the future wine runs as a service with its own account, would wine be able to read the file after someone changed the file's owner from wine to, say user speeddy, or would it just say access denied and not let you read the file, therefore making you have to redo the permissions or make it owned by wine again. A good example would be, say user speeddy wants to be able to edit a file in word sometimes and in kword other times. If in the future wine has it's own account, will wine be able to read AND write the file no matter who it is owned by, without having to modify permissions on the file, or will the user have to change to owner to wine when he wants to modify it in word and change the owner to speeddy when he wants to edit it in kword. Maybe I'm missing the point altogether, but isnt the whole point of having wine as a service in the future to make it easier to use while still being safe? I do believe that some "namby-pamby mouse-addicted beginner" to linux is not going to want to change owners on the file each time he uses a different program to edit it, nor will he even know how to, which therefore makes the useability factor go _way_ down. __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
On Thu, Oct 24, 2002 at 08:08:49AM -0700, Dustin Navea wrote:
or what if someone just changes the owner/group on the file (like a word doc), and then tries to run it with wine, what happens then?
Unless wine has some suid capabilities (which it shouldn't) this has no impact - wine runs in the account of the user who opens the file (runs word).
I was actually thinking more from a read the file standpoint, i.e if in the future wine runs as a service with its own account, would wine be able to read the file after someone changed the file's owner from wine to, say user speeddy, or would it just say access denied and not let you read the file, therefore making you have to redo the permissions or make it owned by wine again.
Just as wine should not be run as root, file i/o in wine should NEVER be done in a security context other than that of the user running the Windows app. Anything that would cause user data files to be written out under a different uid is broken. Steve Langasek postmodern programmer
--- Steve Langasek <vorlon(a)dodds.net> wrote:
On Thu, Oct 24, 2002 at 08:08:49AM -0700, Dustin Navea wrote:
or what if someone just changes the owner/group on the file (like a word doc), and then tries to run it with wine, what happens then?
Unless wine has some suid capabilities (which it shouldn't) this has no impact - wine runs in the account of the user who opens the file (runs word).
I was actually thinking more from a read the file standpoint, i.e if in the future wine runs as a service with its own account, would wine be able to read the file after someone changed the file's owner from wine to, say user speeddy, or would it just say access denied and not let you read the file, therefore making you have to redo the permissions or make it owned by wine again.
Just as wine should not be run as root, file i/o in wine should NEVER be done in a security context other than that of the user running the Windows app. Anything that would cause user data files to be written out under a different uid is broken.
Thats not what I'm saying, what I'm saying is this: wine gets started by an initscript, so that you can run a .exe file by directly double-clicking on it. User Speeddy double-clicks winword.exe, creates a .doc file adds a few lines and saves it. When it gets saves, it gets saves to the *nix fs with owner and group wine. Say later on he wants to try out kword. So he goes to open it in kword, but since he isnt user wine or part of group wine, he gets access denied. So he goes and changes the owner/group to speeddy/speeddy, oepns the file in kword, adds a few more lines, and saves it. Then he decides he doesnt like kword and goes to run it in ms word again. Access denied again because it isnt owned by user/group wine, it is owned by user/group speeddy. So he has to go redo the owner/group again. That is too much of a hassle. Wine could be an almost all-powerful account. Where root is god, wine could be king. root can rwx anything, wine can rw anything... I know the above example is not very common, but it can happen if we have wine running in it's own account, unless the wine account is setup as explained in the end of above paragraph. -Dustin P.S. have I confused everyone enough yet? ;-P __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
Dustin Navea wrote:
--- Steve Langasek <vorlon(a)dodds.net> wrote:
On Thu, Oct 24, 2002 at 08:08:49AM -0700, Dustin Navea wrote:
or what if someone just changes the owner/group on the file (like a word doc), and
then
tries to run it with wine, what happens then?
Unless wine has some suid capabilities (which it shouldn't) this has no impact - wine runs in the account of
the
user who opens the file (runs word).
I was actually thinking more from a read the file standpoint, i.e if in the future wine runs as a service with its own account, would wine be able
to
read the file after someone changed the file's
owner
from wine to, say user speeddy, or would it just
say
access denied and not let you read the file,
therefore
making you have to redo the permissions or make it owned by wine again.
Just as wine should not be run as root, file i/o in wine should NEVER be done in a security context other than that of the user running the Windows app. Anything that would cause user data files to be written out under a different uid is broken.
Thats not what I'm saying, what I'm saying is this: wine gets started by an initscript, so that you can run a .exe file by directly double-clicking on it. User Speeddy double-clicks winword.exe, creates a .doc file adds a few lines and saves it. When it gets saves, it gets saves to the *nix fs with owner and group wine. Say later on he wants to try out kword. So he goes to open it in kword, but since he isnt user wine or part of group wine, he gets access denied. So he goes and changes the owner/group to speeddy/speeddy, oepns the file in kword, adds a few more lines, and saves it. Then he decides he doesnt like kword and goes to run it in ms word again. Access denied again because it isnt owned by user/group wine, it is owned by user/group speeddy. So he has to go redo the owner/group again. That is too much of a hassle. Wine could be an almost all-powerful account. Where root is god, wine could be king. root can rwx anything, wine can rw anything...
Not if you use my proposed setup. speedy ran word with his user, all file access was done with his user. As such, all saves are done accordingly. If you will recall (just lookup my last message to the list), the user can only save stuff into ~speedy/wine (which translates, via symlink, to C:\Documents and Settings\speedy). As such, there is no problem as far as unix permissions are concerned. If speedy next wants to edit the file from unix - no problem. He has full rw access to the file. Other people have access according to what speedy defined. As for impersonation - in order to impersonate, the process must be able to obtain a token belonging to another user. If this is done via password, the standard unix system can be used (be it pam, su, or whatever). If by other means, a more elaborate system can be put in place, but I think we should postpone such discussions. As for running/not running as root - the proper design should allow maximal functionality without root access, while allowing root access. This way we leave maximal control in the hands of the administrator of the machine.
I know the above example is not very common, but it can happen if we have wine running in it's own account, unless the wine account is setup as explained in the end of above paragraph.
-Dustin
P.S. have I confused everyone enough yet? ;-P
__________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
--- Steve Langasek <vorlon(a)dodds.net> wrote:
On Thu, Oct 24, 2002 at 08:08:49AM -0700, Dustin Navea wrote:
or what if someone just changes the owner/group on the file (like a word doc), and then tries to run it with wine, what happens then?
Unless wine has some suid capabilities (which it shouldn't) this has no impact - wine runs in the account of the user who opens the file (runs word).
I was actually thinking more from a read the file standpoint, i.e if in the future wine runs as a service with its own account, would wine be able to read the file after someone changed the file's owner from wine to, say user speeddy, or would it just say access denied and not let you read the file, therefore making you have to redo the permissions or make it owned by wine again.
Just as wine should not be run as root, file i/o in wine should NEVER be done in a security context other than that of the user running the Windows app. Anything that would cause user data files to be written out under a different uid is broken.
Thats not what I'm saying, what I'm saying is this: wine gets started by an initscript, so that you can run a .exe file by directly double-clicking on it. User Speeddy double-clicks winword.exe, creates a .doc file adds a few lines and saves it. When it gets saves, it gets saves to the *nix fs with owner and group wine. Say later on he wants to try out kword. So he goes to open it in kword, but since he isnt user wine or part of group wine, he gets access denied. So he goes and changes the owner/group to speeddy/speeddy, oepns the file in kword, adds a few more lines, and saves it. Then he decides he doesnt like kword and goes to run it in ms word again. Access denied again because it isnt owned by user/group wine, it is owned by user/group speeddy. So he has to go redo the owner/group again. That is too much of a hassle. Wine could be an almost all-powerful account. Where root is god, wine could be king. root can rwx anything, wine can rw anything... I know the above example is not very common, but it can happen if we have wine running in it's own account, unless the wine account is setup as explained in the end of above paragraph. -Dustin P.S. have I confused everyone enough yet? ;-P __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
Le jeu 24/10/2002 à 14:19, Dustin Navea a écrit :
[Snip]
Thats not what I'm saying, what I'm saying is this: wine gets started by an initscript, so that you can run a .exe file by directly double-clicking on it.
No need to setup a initscript for that, or have Wine run as a special user. With the binfmt module properly setup, if your PE file is x, then you can run it as any other ELF or script. Or, with Konqueror/Nautilus, link .exe files to Wine. No need for a special account. The need for a special account can come if you want to have a shared fake (or real) Windows installation across all users on the system. And even then, it's only because some applications will want write access to system dirs. If all applications behaved properly (ie, not in a Win9x "I can do whatever I want in c:\windows" fashion), then it'd be even simpler to do, and Wine can probably already cope with that.
User Speeddy double-clicks winword.exe, creates a .doc file adds a few lines and saves it. When it gets saves, it gets saves to the *nix fs with owner and group wine. Say later on he wants to try out kword. So he goes to open it in kword, but since he isnt user wine or part of group wine, he gets access denied. So he goes and changes the owner/group to speeddy/speeddy, oepns the file in kword, adds a few more lines, and saves it. Then he decides he doesnt like kword and goes to run it in ms word again. Access denied again because it isnt owned by user/group wine, it is owned by user/group speeddy. So he has to go redo the owner/group again. That is too much of a hassle.
Small question: how the wine user could get write access to $HOME? (your proposition below is not a good idea IMHO)
Wine could be an almost all-powerful account. Where root is god, wine could be king. root can rwx anything, wine can rw anything...
Not sure at all it's a good idea. Expecially the rw thing, for which you'll need kernel support (which I don't think would be integrated in the official one).
I know the above example is not very common, but it can happen if we have wine running in it's own account, unless the wine account is setup as explained in the end of above paragraph.
I think what the discussion diverged to is how to setup (securely) Wine so that it's easy to install system-wide (accessible to all users) a program/driver. The easy solution would be to setup a wine-user user, put the fake_windows in /usr/local/fake_windows, have all files rw-rw-r-- (x for .exe if using binfmt), and have wine-user owner on all those files.You install/remove software using only that user (since he only has write access). That way, it looks a lot like in most computer labs where the user cannot (or should not) access the system/apps, but is free in his own account. Also, remember that a lot of Windows apps have difficulties coping with multiple users (think permissions), and even more with multiple simultaneous uses, although things like TerminalServer helps on that front to keep developers in check.
-Dustin
P.S. have I confused everyone enough yet? ;-P
No me (yet :) Back to the services part, I agree with Alexandre: do we have something needing services now, and is it worth it to support all of it. Vincent
Am Don, 2002-10-24 um 17.08 schrieb Dustin Navea:
I was actually thinking more from a read the file standpoint, i.e if in the future wine runs as a service with its own account, would wine be able to read the file after someone changed the file's owner from wine to, say user speeddy, or would it just say access denied and not let you read the file, therefore making you have to redo the permissions or make it owned by wine again.
In the near future this would depend on whether wine's account has (group or world) rights on speedy's word file. Actually in the near future the user is far more likely to start a separate instance of wine in his own account for editing his word files. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
--- Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> wrote:
Am Don, 2002-10-24 um 17.08 schrieb Dustin Navea:
I was actually thinking more from a read the file standpoint, i.e if in the future wine runs as a service with its own account, would wine be able to read the file after someone changed the file's owner from wine to, say user speeddy, or would it just say access denied and not let you read the file, therefore making you have to redo the permissions or make it owned by wine again.
In the near future this would depend on whether wine's account has (group or world) rights on speedy's word file. Actually in the near future the user is far more likely to start a separate instance of wine in his own account for editing his word files.
That is what I'm trying to say, do we really want to give world rights to wine? That could be a security hole in and of itself. __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
On Thursday 24 October 2002 04:12 am, Martin Wilck wrote:
This thread has immediately jumped to the future-development discussion
:-)
sorry. my fault. I guess that stems from me not having a good answer to the actual question you were asking :)
A system administrator already could do this. Anyhow there's really no need to bring sudo into the picture. If a sysadmin is crazy enough to want to run a wine "service" as root,
Wine shouldn't run as root. I don't see strong arguments against running a wine service in a dedicated non-root Unix user account, though.
agreed.
they could just invoke their executable from an init script; that's more "service" like anyhow.
That has nothing to do with the Windows service API and won't help you a bit trying to port a Windows app that uses that API.
OTOH, I guess sudo could be used like this: if we are going to go the route of "being uncompromisingly unixey" then the services API should just manipulate init scripts.
IMO a bad idea, this comes down to real root access for wine. I'd rather install a single init script starting a daemon that
also agreed; I was just playing devil's advocate.
- changes uid/gid to a dedicated unix account with non-root privileges, - (perhaps) does a chroot(), - starts wine.
The wine process would then start all registered Windows services in his environment. An "autostart" service would mean that the process is started when the first wine process starts. To stop the services, we'd need a "shutdown" application of some sort.
Obviously this would require wineserver calls, no idea if a server protocol extension would be necessary.
Controlling these services would require a su(1) to the service account and starting a windows service-control executable.
this is a totally viable approach. It does begin to beg the question of whether wine would have to move from per-user installations to shared installations... but those issues are not insurmountable.
This way, a user could "be administrator" within wine, but not be root on their unix box.
If you think about it, this is exactly the situation that we have now, and it's not so bad after all. No restrictions in the Win environment, but normal user privileges from the Unix perspective.
this is currently more a side-affect of a missing security implementation than a result of clever engineering. I guess what I mean above is that, as we implement security features, we need to preserve this capability, and it seems most agree.
And if the user creates a symlink, all hell breaks loose because fake_windows becomes a mix of files owned by root and files owned by the user. I could concoct tons of similar examples. But I'll spare you the bandwidth.
This could be solved by a system-wide wine installation with its own security handling. All installed files would (in the Unix sense) belong to the user the wine process is running as. For very good reasons that user shouldn't be root.
yup. now we have big open questions, however: what parts of wine should be "shared" and owned by the "wine" user? What parts are per user? etc... That doesn't mean I don't like this approach, btw. But it's a significant change, and would take some careful thought and some significant time at the drawing board.
Once we start getting more sophisticated about W32 security (and it seems to me, based on recent discussion, that this time is coming sooner than later), it's going to be inappropriate to continue with this approach, because we don't want to encourage users to do wine stuff as root.
I can't follow you here - **wine must not be run as root**, and we can't do anything but repeat that over and over again, whether or not we implement services and/or security management in wine.
? I'm afraid I don't follow either. Doesn't matter; we seem to be in agreement about wine-as-root. I would make one exception: if certain things need to happen as different unix users, there is going to have to be some process running which is capable of executing "become user" calls. So, for example, I could imagine something like rootwineserver (runs as root. does almost nothing but spawn wineservers) | +-- wineserver -u 'fred' (runs as fred) | +-- wineserver -u 'bob' (runs as bob) | +-- wineserver -u 'winesystem' (runs as winesystem; rough equiv. to NT SYSTEM acct.) | +-- wineservices (runs as winesystem) | +-- service 1 (runs as winesystem) | +-- service 2 (runs as winesystem) This is something like how sshd works. rootwineserver could be a pure-unix program that runs as root, and takes care of a very small set of truly priveleged operations (like listening on priveleged ports and spawning processes as other users). The wineserver -u winesystem process could do "virtually priveleged" operations which require priveleged access in windows but not unix (priveleged registry access, authentication, etc). Even the above model is too simple if, for example, we truly want to do impersonation, or allow services to start as different users as configured in the registry, etc. Some of these features might require a disconnect between the concept of unix process parentage and windows process parentage, since, for example, for wineservices to launch a service process as 'fred', the unix process would probably need to be launched by rootwineserver. I don't mean to suggest an implementation, but just to point out that, if properly implemented, "no wine stuff as root" doesn't need to be an absolutely hard-and-fast rule; personally I would not object to a rule of "absolutely as little wine stuff as root as possible," sometime down the road.
In any case, if a future wine did its own security management, the users and groups must still map to Unix users and groups - if not, how would such a future wine determine the access rights of a Unix file that only shows Unix user/group permissions?
Yes, but the operative term is 'map': samba provides an example of how this could be done. Frankly, it is confusing and a bit of a hassle, but a little database that maps unix users to "windows" users can go a long way towards addressing certain problems. The counterargument to such an approach is that it creates unneccesary confusion, complexity, and administrative hassles (and samba does, indeed suffer from these symptoms, but not unreasonably so IMHO). Anyhow, talk is cheap so I will shut up about his now, before I end up writing code :) -- gmt "Oh, and of course, the fastest way to dig a tunnel is to dig at both sides." -- The Linux Advanced Routing HOWTO
Greg Turner <gmturner007(a)ameritech.net> writes:
This is something like how sshd works. rootwineserver could be a pure-unix program that runs as root, and takes care of a very small set of truly priveleged operations (like listening on priveleged ports and spawning processes as other users). The wineserver -u winesystem process could do "virtually priveleged" operations which require priveleged access in windows but not unix (priveleged registry access, authentication, etc).
Even the above model is too simple if, for example, we truly want to do impersonation, or allow services to start as different users as configured in the registry, etc. Some of these features might require a disconnect between the concept of unix process parentage and windows process parentage, since, for example, for wineservices to launch a service process as 'fred', the unix process would probably need to be launched by rootwineserver.
IMO the real question is what do we need this for? Sure we can use Unix mechanisms to emulate running services as different users etc. but is that really what we need? What are these services doing that requires switching users? Is that how we want it to be done under Unix? I think that if an application really requires extensive compatibility with the Windows security mechanism, then it may not be a good idea to run it under Unix at all, since it probably won't do what you want anyway. So what are the real world cases that require these kinds of things? -- Alexandre Julliard julliard(a)winehq.com
On Thu, Oct 24, 2002 at 01:32:06PM -0400, Dimitrie O. Paun wrote:
On October 24, 2002 01:30 pm, Alexandre Julliard wrote:
So what are the real world cases that require these kinds of things?
Well, not many I guess, Just For Fun (TM). Kindda like running Wine, under Cygwin, under Windows... :)
With the important difference that giving Wine the power to change userids "just for fun" will inevitably lead to uninformed users mucking up the security of their systems. Steve Langasek postmodern programmer
On Thursday 24 October 2002 12:30 pm, Alexandre Julliard wrote:
So what are the real world cases that require these kinds of things?
that's a good question. here's another: of these real-world cases, which are realistic, near targets, i.e., pre 0.9, or pre 1.0? Does SQL Server fall into this category? Print-driver installation like in the Adobe Acrobat case I mention above? I've seen proposals for SMB support which do and do not fall into these categories.... and AFAIK we still don't have an answer to Martin's original question about whether we care about the services APIs yet, and if so, how to go about implementing them. In most cases, it's easy to imagine work-arounds; one could argue that this is a premature discussion. Once RPC and DCOM start working, I imagine some new things will come up that need adressing; it's hard for me to predict what these would be, however. -- gmt "Oh, and of course, the fastest way to dig a tunnel is to dig at both sides." -- The Linux Advanced Routing HOWTO
Am Don, 2002-10-24 um 19.30 schrieb Alexandre Julliard:
I think that if an application really requires extensive compatibility with the Windows security mechanism, then it may not be a good idea to run it under Unix at all, since it probably won't do what you want anyway. So what are the real world cases that require these kinds of things?
I have a real-world example for an application needing the service API and the logevent API. No user-account switching and "extensive compatibility with the Windows security mechanism" is required. It could very well be run in a special account, and doing that would IMO not raise substantial security issues. All that's needed is a working service implementation in the sense that services can be registered which wine would start automatically when it's launched. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
participants (8)
-
Alexandre Julliard -
Dimitrie O. Paun -
Dustin Navea -
Greg Turner -
Martin Wilck -
Shachar Shemesh -
Steve Langasek -
Vincent Béron