Hello again,
(FYI, I took the liberty to change the topic since I started the former thread "How is Win/Dos syscalls implemented in Wine?" which I feel has gone a little bit off-topic)
I had some more thoughts on the issue...
I believe most wine users trust wine not to touch anything outside of its configured drive space. Malicious Linux/Unix syscalls could be embedded in windows apps and if executed do a great deal of damage. After all checking your app is run whithin Wine is not that hard (reading registry settings for instance). Lets call such an malicious app a wine-virus from now on. At present a wine-virus would even be allowed to fork itself, leaving the wine environment and continue to run even after you shutdown the wineserver, and in some cases even after the user logs out. The virus would now have full access to the system whithin the users permission, doing much greater damage than you expected.
The question is...Would you expect that damage from running a windows app in wine, when you know it could be safely run in Windows? In just a few embedded bytes in the code it could remove your home directory in a single syscall. Would you expect that? - I wouldnt.
I really love the idea of Wine, and the fact that its working good and rather stable now does mean its gaining popularity and a broader user base, which further IMHO accelerates the wine movement. If wine users were aware of the risks of using wine at present, I believe wine would be used more cautiously.
Cant we atleast try implement some protection in wine against these attacks, before something really nasty happens. I do think company policy decissions againt using wine, will do just as much damage to the wine movement as too the free software movement at large.
I would, despite my current lack of knowledge, gladly offer my help. But I hope someone more experienced would take the lead.
Best Regards,
Peter Andersson
Peter Andersson a écrit:
Hello again,
(FYI, I took the liberty to change the topic since I started the former thread "How is Win/Dos syscalls implemented in Wine?" which I feel has gone a little bit off-topic)
I had some more thoughts on the issue...
I believe most wine users trust wine not to touch anything outside of its configured drive space.
"Trust" might be a bit too heavy. "Believe" would be more appropriate. Running Wine is (and has always been) a bit of a security risk, the same way (although to a lesser extent) than say SUID libsvga apps. That's why, if you think the risks exceed what you are ready to bear, then don't use it on your systems.
Malicious Linux/Unix syscalls could be embedded in windows apps and if executed do a great deal of damage.
The same way they can be embedded in any Linux native trojan.
After all checking your app is run whithin Wine is not that hard (reading registry settings for instance). Lets call such an malicious app a wine-virus from now on. At present a wine-virus would even be allowed to fork itself, leaving the wine environment and continue to run even after you shutdown the wineserver, and in some cases even after the user logs out. The virus would now have full access to the system whithin the users permission, doing much greater damage than you expected.
It doesn't have any more permission than any other closed-source app you run on your system. Are you that sure that, let's say, UT2K3 (or any other closed-source or even open-sourec native Linux app) won't try to do that, either maliciously or by accident?
The question is...Would you expect that damage from running a windows app in wine, when you know it could be safely run in Windows?
How do you know it _is_ safe to run in Windows? Because you never had a problem running it? Hardly a proof, no?
In just a few embedded bytes in the code it could remove your home directory in a single syscall. Would you expect that? - I wouldnt.
No need for convulated interrupt calling. Just call (through system()) something along the lines of "/bin/sh -c /bin/rm -rf /" (beware, don't actually *do* that!) to get that effect. Since the deletion is done through /bin/rm rather than a Wine (or your app) libc call, then anything you add to protect from this in Wine won't help.
"Then don't allow Win32 apps to run Unix apps."
Ok. Then include a Winelib app which will call that Unix app. You *do* want us to allow the calling of Winelib apps, don't you? Else, you wouldn't be able to run notepad.exe.so from an installer to see the release notes.
And since a Winelib app is a native Unix app, adding something to Wine wouldn't help.
I really love the idea of Wine, and the fact that its working good and rather stable now does mean its gaining popularity and a broader user base, which further IMHO accelerates the wine movement. If wine users were aware of the risks of using wine at present, I believe wine would be used more cautiously.
It should already be used cautiously.
Cant we atleast try implement some protection in wine against these attacks, before something really nasty happens. I do think company policy decissions againt using wine, will do just as much damage to the wine movement as too the free software movement at large.
If you want to implement some of those protections, they should belong at another level, in which case not only Wine would benefit from them.
And don't forget that if you try to build a wall in an open field, there will probably be some gaping holes around, over or under it. Beginning to erect that wall would (IMHO) just entice some people to try to circumvent it.
Use the LSM patches for Linux if you want to monitor certain system calls. Use Wine in UML, chroot, or as a separate user (*not* as SUID) if you want to protect your current $HOME.
I would, despite my current lack of knowledge, gladly offer my help. But I hope someone more experienced would take the lead.
Best Regards,
Peter Andersson
Vincent
On Saturday 26 October 2002 08:32 pm, Vincent Béron wrote:
Peter Andersson a écrit:
Malicious Linux/Unix syscalls could be embedded in windows apps and if executed do a great deal of damage.
And don't forget that if you try to build a wall in an open field, there will probably be some gaping holes around, over or under it. Beginning to erect that wall would (IMHO) just entice some people to try to circumvent it.
Use the LSM patches for Linux if you want to monitor certain system calls. Use Wine in UML, chroot, or as a separate user (*not* as SUID) if you want to protect your current $HOME.
Vincent
I concur with Vincent, here. As wine exists here and now, we are basically implementing the level of "security" provided by Windows 9x. That is, wine "emulates" an OS with no security measures at the filesystem level, no security policy regarding what API's can be called (except as provided by the CPU itself), and so on.
Luckily, the native operating systems that host wine tend to be rich with security features, and those can be used to sandbox wine until some more sophisticated application-level security measures exist.
We've recently talked about some ways to move forward towards implementing the NT-style security model in wine. When those plans move forward, one of the issues to consider is the tendency of windows to propogate virii, and the possible need to selectively prohibit wine from accessing resources that the user invoking wine might have full control of.
Unless wine is going to be a true emulator (instead of an engine for executing windows apps natively under the security context of the invoking user), we simply cannot solve this "problem," by definition.
The closest thing to a solution involves a massive reconceptualization of how wine works (for example, the invoking user runs userwine, which uses some kind of IPC to talk to sandbox-wine, which does all the actual executing of windows code or, alternatively, wine works like a just-in-time compiler, verifying code is safe before it's loaded into memory (terrible idea IMHO)). Since "emulating" the NT security model for wine is a similarly major undertaking, and provides most of the same benefits as Peter would have, I think this is how we should solve this "problem".
Food for thought: by Peter's definition, neither Windows, nor most Unix operating systems, provide an acceptable level of security. Wine is no better, but also no worse, than any other powerful application, such as GNU make, bash, or the Konqueror file browser, from a security perspective. All of these can be used to destroy your $HOME directory and any other file you can delete.
I think the problem is one of wine being closely associated with Windows, and windows having a reputation of being insecure; in other words, it's a problem of perception, not of technical merit. Nothing wrong with that -- problems of perception can kill a project -- but bear in mind that, if wine, even as it exists today, is run in a carefully administered manner on a good secure OS, it ought to be safer than native Windows to run, if you accept the assumption that UNIX-like OS's are more secure than Windows ones. If you really don't trust windows, you could argue that running under wine in a sandbox is the /only/ safe way to run windows programs outside of an emulator.
Just my opinion, probably worth about what you paid for it, but there you go.
On Sat, 26 Oct 2002, Greg Turner wrote: [...warning: slight reordering...]
I think the problem is one of wine being closely associated with Windows, and windows having a reputation of being insecure; in other words, it's a problem of perception, not of technical merit. Nothing wrong with that -- problems of perception
[...]
I concur with Vincent, here. As wine exists here and now, we are basically implementing the level of "security" provided by Windows 9x. That is, wine "emulates" an OS with no security measures at the filesystem level, no security policy regarding what API's can be called (except as provided by the CPU itself), and so on.
I agree that there is a problem of perception so I will quickly clarify the above sentence, lest it be mis-interpreted and contribute to that perception problem.
When reading 'wine "emulates" an OS with no security measures at the filesystem level' I think most people will think that Windows applications running under Wine can read and modify any file on the Unix system, including system files and files not belonging to the user running the application. This is of course not the case!
What Vincent says is that Wine does not implement the Windows APIs that let a process query or specify ACLs on files or kernel objects, and query or switch user or group ids. In this respect, it is closer to Windows 9x than Windows NT.
However while on Windows 9x this means a process can modify any file on the system (i.e. no security at all), in Wine this just means that Windows applications run under the Unix security model, but have no way to even tinker with it using their usual (Win32) API.
So to sum up: * Win9x No security * Wine Unix security model. * Windows NT/2000/XP NT security model, i.e. an ACL-based one. (only if using an NTFS filesystem)
(however I will quickly point out that the NT security model suffers from a serious design flaw which lets processes escalate privileges in a way which is currently simply impossible in Wine, for more details see http://security.tombom.co.uk/shatter.html)
[...]
Since "emulating" the NT security model for wine is a similarly major undertaking, and provides most of the same benefits as Peter would have, I think this is how we should solve this "problem".
AFAIK the Win32 API (unlike the Unix API, see chroot) does not make it possible to prevent a process from accessing or modifying files belonging to the current user.
On Saturday 26 October 2002 11:43 pm, Francois Gouget wrote:
On Sat, 26 Oct 2002, Greg Turner wrote:
That is, wine "emulates" an OS with no security measures at the filesystem level, no security policy regarding what API's can be called (except as provided by the CPU itself), and so on.
I agree that there is a problem of perception so I will quickly clarify the above sentence, lest it be mis-interpreted and contribute to that perception problem.
When reading 'wine "emulates" an OS with no security measures at the filesystem level' I think most people will think that Windows applications running under Wine can read and modify any file on the Unix system, including system files and files not belonging to the user running the application. This is of course not the case!
good call. thanks for that clarification.
(however I will quickly point out that the NT security model suffers from a serious design flaw which lets processes escalate privileges in a way which is currently simply impossible in Wine, for more details see http://security.tombom.co.uk/shatter.html)
seen this one, too. interesting article; there's an even more interesting follow up at http://security.tombom.co.uk/moreshatter.html. If were very careful to do everything "just like windows" I think we could reproduce these flaws in a year or two :)
At http://security.tombom.co.uk/aboutfoon.html, the author (who calls himself "Foon") boasts "Able to program in 23 languages on 14 platforms, Foon takes an average of 3 days to learn a new programming language." ... That means he's spent exactly 69 days learning programming languages en toto.
AFAIK the Win32 API (unlike the Unix API, see chroot) does not make it possible to prevent a process from accessing or modifying files belonging to the current user.
This is another argument for a permissions mapping scheme instead of direct translation of Unix permissions to wine permissions, as I see it. Of course, this leads us back to the Wine Is Not an Emulator "problem" as previously discussed... so I guess I'm going in mental circles and, in a sense, contradicting myself... time to shut up and get back to work on RPC :)
Peter Andersson kanelballe@softhome.net writes:
The question is...Would you expect that damage from running a windows app in wine, when you know it could be safely run in Windows? In just a few embedded bytes in the code it could remove your home directory in a single syscall. Would you expect that? - I wouldnt.
You should. If you run untrusted code under your account it can do anything that you are allowed to. This is exactly equivalent to running an untrusted Linux app. From a security standpoint there is absolutely no difference between a Windows binary running under Wine and a Linux binary running natively.
You can use the DOS drive configuration to limit the potential problems a bug in a Windows app can cause; but it is impossible to protect against malicious code except by not running it. Wine is not, and cannot be, a sandbox for running untrusted code.
Cant we atleast try implement some protection in wine against these attacks, before something really nasty happens.
No, we can't.
Peter Andersson kanelballe@softhome.net writes:
The question is...Would you expect that damage from running a windows app in wine, when you know it could be safely run in Windows? In just a few embedded bytes in the code it could remove your home directory in a single syscall. Would you expect that? - I wouldnt.
You should. If you run untrusted code under your account it can do anything that you are allowed to. This is exactly equivalent to running an untrusted Linux app. From a security standpoint there is absolutely no difference between a Windows binary running under Wine and a Linux binary running natively.
You can use the DOS drive configuration to limit the potential problems a bug in a Windows app can cause; but it is impossible to protect against malicious code except by not running it. Wine is not, and cannot be, a sandbox for running untrusted code.
Cant we atleast try implement some protection in wine against these attacks, before something really nasty happens.
No, we can't.
I really agree that wine is safe enough. However, we should always remember that wine is bound to be used by former win users, who may have no concern about security. I often hear about people running wine as root or mapping '/' to a wine drive. I think that the wine code should protect the system from such _users_! Here is what I would do: Write a segment of code that will abort wine, if it is run as root (that is, just before wine starts anything). This piece of code should only be explicitly disabled in the 'configure' script. That way, only a wine-developer will be able to cause wine to run as root. It has to be that hard to do so. We should then stop hearing claims that 'wine is unsafe'.
My $0.02,
I always though of a wine as way to run windows apps better than windows.
Better also means "more secure" for me.
A way to make it more secure is to catch key API calls and decide if the application is allowed to run it or not.
This would be easy to detect if an application is trying to delete a file, to open a network connection, or anything that could be possible unsafe if not used correct.
As this would be implemented in wine (as opposed in the host OS, e.g. the Linux kernel) a Dialog could pop up telling the user what the app is trying to do and how the user would like to proceed, like: <allow this time>, <allow this session>, <always allow>, <deny this time>, ... and so on.
This could be configured in the config as the dll loading is done now in a per app way or generic (all apps) way.
Of course, this being implemented in wine as a wrapper to such API calls would slow the performance a little, so wine could be compiled with '--disable-runtime-security' is configure or something like that. This way wine could be compiled just as if this feature did not existed (as it is now).
I know this is not a priority to wine project right nowand there is a lot of things to be done to get to wine 0.9 and 1.0.
However, I do think that just setting this to a OS problem and that wine should not care about this is wrong. Maybe this is just not the right time to implement this, but this shouldn't be banned.
I agree that you shouldn't run any untrusted code as people would not do with Linux/Bsd/..., however there is a strong point here.
99.9999% of win32 applications is closed source. There is no way to trust them.
Even common ones like MS Office can be exploited and used to run mallicious code. Codeweavers would need to handle this later on.
Internet Explorer can run potencially untrusted/dangerous code with ActiveX from webpages. And its use is already advertised with Codeweavers Xover Office (not supported though).
Many programs already install some kind of spyware nowadays, like any p2p as Kazaa, morpheus, edonkey2000, ...
Even RealPlay used to send private information thru the net.
As Wine gets more and more reliable to run win32 applications and Microsoft change its EULA to not run applciations like Media Player in other OSes that Windows. And this discussion of syscalls that only wine as a linux application could do, could make future versions of MS apps use this to exploit limitations as the wine drivers and wipe everything it has permissions to. And this would be leagal as no one really reads the EULA.
Note that I did not get to the merity of Virus that nowadays are the number one reason people are moving to (or willing to) Linux.
Wine could implement a clean Security Layer: YES
Is this a priority for Wine Project: NO (not yet at least)
This kind of stuff is what would make Wine a possibility run run Windows Apps better than Windows.
Because of this points, I would like to ask Alexandre to not deny the possibility to a developer to try to implement this kind of layer of security.
I agree that this needs to be deeply discussed on how it should be implemented and that after some start to implement this, this could take a long time before being merged in the main tree.
However, this is not just a OS problem IMO.
Regards,
Raul Dias
Alexandre Julliard julliard@winehq.com wrote:
Peter Andersson kanelballe@softhome.net writes:
The question is...Would you expect that damage from running a windows app in wine, when you know it could be safely run in Windows? In just a few embedded bytes in the code it could remove your home directory in a single syscall. Would you expect that? - I wouldnt.
You should. If you run untrusted code under your account it can do anything that you are allowed to. This is exactly equivalent to running an untrusted Linux app. From a security standpoint there is absolutely no difference between a Windows binary running under Wine and a Linux binary running natively.
You can use the DOS drive configuration to limit the potential problems a bug in a Windows app can cause; but it is impossible to protect against malicious code except by not running it. Wine is not, and cannot be, a sandbox for running untrusted code.
Cant we atleast try implement some protection in wine against these attacks, before something really nasty happens.
No, we can't.
-- Alexandre Julliard julliard@winehq.com
On Thursday 31 October 2002 08:10 am, Raul Dias wrote:
My $0.02,
A way to make it more secure is to catch key API calls and decide if the application is allowed to run it or not.
not a bad idea.
Wine could implement a clean Security Layer: YES
Clean, perhaps, but secure? That depends on what you are trying to achieve: since the unix API is available to apps running under wine, such measures will only secure applications which don't specifically check for wine and circumvent its api-level security measures.
So, for example, this could be used to protect a system against security flaws in Internet Exploder or Outlook... but a malicious virus writer could work around winapi-based security provisions, as discussed earlier in this thread.
On Thursday 31 Oct 2002 10:00 am, Greg Turner wrote:
On Thursday 31 October 2002 08:10 am, Raul Dias wrote:
My $0.02,
A way to make it more secure is to catch key API calls and decide if the application is allowed to run it or not.
not a bad idea.
Wine could implement a clean Security Layer: YES
Clean, perhaps, but secure? That depends on what you are trying to achieve: since the unix API is available to apps running under wine,
This subject interests me a great deal so please humour me as I try to wrap my head around the wine-specifics well enough to get an accurate(ish) picture of this. I'm a security person, but no win32 expert and even less of a PE/ELF hacker...
First I can understand the point made that, at the end of the day, the only *actual* security you can force on a wine-loaded application is whatever security the operating system forces on *all* applications (wine-loaded or otherwise) running as the same user. Ie. even if a win32 application loaded under wine couldn't directly call ioctl(), unlink(), or fopen(), the binary code could still *reimplement* those functions in assembly. I also realise that other assembly hacks (or just trail-and-error "luck" virii) could scan the process's memory space looking for likely function pointers, file-descriptors, etc and start meddling with them directly to bypass the wine-implemented win32 API. Does that seem a reasonable understanding of the situation?
My next question is this: why is the unix API available to wine-loaded PE apps/libs? I can't see a single compelling reason for this, though I'm prepared to be illuminated otherwise. If we discard memory-scanning and other assembly tricks for a moment and consider just the case of PE apps/libs generated from "clean C" (and "clean compilers"); then preventing any direct binding of any wine-loaded PE images to native ELF images, *except* those implemented by wine, immediately raises the bar. Of course, I'm assuming this is *possible* with the PE (and ELF) format(s)?
My problem with discarding the "clean" security layer because it isn't perfectly impenetrable in a technical sense, is that it is purely an abstract technical-only view of things, and Wine's role (and threat-model for its future success) is anything but purely technical. Jeremy, I'd be particularly interested if you have any thoughts on this. AFAICS, this idea is not just a question of security by obscurity - there are technical and "political" issues involved too.
First, not linking PE images to non-wine ELF images allows one to define a security policy in wine for win32/PE executable code akin to a "rules for Win32 programs" config. One possibility here is the kind of thing Raul was discussing. Buggy programs aren't programs that try to detect if they're running in wine and if so do damage - buggy programs are programs using the win32 API written by careless win32 bunnies. *Those* programs could be subject to a policy configuration that would allow you to selectively restrict things in a way that will *always* be better than what MS-windows provides - whether the programs are horribly buggy or really solid. In other words, a configurable real-world control/protection against potentially buggy win32 code (that would be equally buggy on MS-windows and Wine after all).
Second, if the PE loader doesn't blindly link PE apps/libs to native libraries, then bypassing the wine-implemented win32 API (and thus the policy configuration) would require an *explicit* workaround on the part of the programmer. Putting in assembly code to prime registers and fire interrupts that (a) on linux would getenv("HOME") and unlink() the result, and (b) on windows would probably just crash with a BSOD is what the security community call a "virus". :-) It doesn't have to be difficult for the programmer to do it, it just has to require him/her to be malicious and unambiguously *intend* to do it. Writing and distributing one of these things opens you up to criminal prosecution in many jurisdictions, and also allows McAfee and friends to assign a signature to corresponding binaries and get them classified as a virus (and their authors classified as bad people).
Or put another way - as Wine converges on "beta" or "release" level and Wine + XXX/OS (where XXX=Linux,FreeBSD,etc) becomes not only a competitor to MS-windows, but in fact offers considerable advantages, where then will the *threats* to wine lie?? I would certainly like to (a) see the flexibility of being able to apply a "soft" security policy for win32 applications in the wine-implemented win32 API, (b) force win32 developers who are "anti-wine" and "pro-monopoly" to have to expose themselves to criminal possibilites if they want to bypass wine-based execution configuration and controls (or worse, if they want to package anti-wine trojans).
So, for example, this could be used to protect a system against security flaws in Internet Exploder or Outlook... but a malicious virus writer could work around winapi-based security provisions, as discussed earlier in this thread.
Yes, and I think the point that's worth making is that writing a malicious virus against wine is not only a crime in the sense that normal virus-writing is a crime, but also has anti-trust/anti-competition overtones ... when you try to imagine which companies would most like their win32-based applications to *NOT* run on wine (and perhaps even hurt wine users), you might understand where I'm coming from.
In lieu of "pure" security enforcements (which would require virtualisation anyway which Wine is not in the business of), I think a "win32-API-based" security approach is worthwhile. If I can write win32 apps that link directly to libc, I could elect to replace the file-management subsystem of my app with a POSIXy layer that is only used on wine "for performance reasons only, honest!". This would mean (a) Wine's file-system configuration can be bypassed, and (b) I could (perhaps deliberately) embed nasty corruption bugs in my POSIX subsystem but have my win32 subsystem very stable. This program would just be "unstable on wine" but not "anti-competitive" nor "criminal". But if you don't let applications do this in wine's PE-loader (or at least let it be controllable in the config) then acheiving the same result would require me to write a genuine virus instead (and so open myself to anti-trust/criminal accusations).
Thoughts?
Cheers, Geoff
Greg Turner gmturner007@ameritech.net wrote:
On Thursday 31 October 2002 08:10 am, Raul Dias wrote:
My $0.02,
A way to make it more secure is to catch key API calls and decide if the application is allowed to run it or not.
not a bad idea.
Wine could implement a clean Security Layer: YES
Clean, perhaps, but secure? That depends on what you are trying to achieve: since the unix API is available to apps running under wine, such measures will only secure applications which don't specifically check for wine and circumvent its api-level security measures.
So, for example, this could be used to protect a system against security flaws in Internet Exploder or Outlook... but a malicious virus writer could work around winapi-based security provisions, as discussed earlier in this thread.
In this case I agree that the OS should provide the security layer, not wine.
Wine should provide security only for (or "at least for") WIN32 API flaws.
[]'s Raul Dias
-- gmt
"The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993
On Thu, Oct 31, 2002 at 11:10:33AM -0300, Raul Dias wrote:
My $0.02,
I always though of a wine as way to run windows apps better than windows.
Better also means "more secure" for me.
A way to make it more secure is to catch key API calls and decide if the application is allowed to run it or not.
This would be easy to detect if an application is trying to delete a file, to open a network connection, or anything that could be possible unsafe if not used correct.
...
The whole issue can probably addressed by very simple sandboxing:
Just use a WINE pseudo user.
Then WINE and the windows applications can do only damage within the pseudo user context, which should be harmless.
Automated cleanup (like cron based kills or similar) would be easy.
Drawback: Does not scale well to a multi user system.
Ciao, Marcus
Marcus Meissner wrote:
On Thu, Oct 31, 2002 at 11:10:33AM -0300, Raul Dias wrote:
My $0.02,
I always though of a wine as way to run windows apps better than windows.
Better also means "more secure" for me.
A way to make it more secure is to catch key API calls and decide if the application is allowed to run it or not.
This would be easy to detect if an application is trying to delete a file, to open a network connection, or anything that could be possible unsafe if not used correct.
...
The whole issue can probably addressed by very simple sandboxing:
Just use a WINE pseudo user.
Then WINE and the windows applications can do only damage within the pseudo user context, which should be harmless.
Automated cleanup (like cron based kills or similar) would be easy.
Drawback: Does not scale well to a multi user system.
Ciao, Marcus
And, as all sandbox designs, is not very practical to use, even for a single user. I'm talking access to documents, etc.
And nothing prevents a rogue app to either access the network (and send stuff you feed it), or wipe your fake windows.
OTOH, the potential damage is still somewhat contained.
In the end, I'd say don't expect any more security than what the host OS can already provide to you.
Vincent
On Sun, 27 Oct 2002, Peter Andersson wrote: [...]
I believe most wine users trust wine not to touch anything outside of its configured drive space. Malicious Linux/Unix syscalls could be embedded in windows apps and if executed do a great deal of damage. After all checking your app is run whithin Wine is not that hard (reading registry settings for instance). Lets call such an malicious app a wine-virus from now on. At present a wine-virus would even be allowed to fork itself, leaving the wine environment and continue to run even after you shutdown the wineserver, and in some cases even after the user logs out. The virus would now have full access to the system whithin the users permission, doing much greater damage than you expected.
The question is...Would you expect that damage from running a windows app in wine, when you know it could be safely run in Windows? In just a few embedded bytes in the code it could remove your home directory in a single syscall. Would you expect that? - I wouldnt.
[...more snipped...]
Certainly I would be surprised to see a Wine-aware virus tomorrow. In that sense I certainly would not expect this sort of thing to happen tomorrow. But you seem to be confused about the goal of Wine.
The goal of Wine is to run Windows applications on Unix. Windows applications run through Wine should be able to do no more and no less than any other Linux application. Thus Wine is not more of a security risk than any other piece of (somewhat alpha) software.
But the goal of Wine is *not* to build a sandbox or a virtual machine in which you can safely run malicious code. If that is what you want, then you should look at chroot, jail, User Mode Linux, VMWare or Plex86. You can even combine them with Wine to build sandboxes. For instance you could run Wine in a 'jail' environment and then a Wine-aware would be confined to that environment.
That being said, yes it is possible to configure Wine such that Windows applications are confined to a small portion of your disk. It is a useful feature and, as far as I know, it should work against all current Windows viruses. Of course, when configured this way Wine is not very useable. You would not be able to use Word to edit your documents for instance... that is unless you menually copy the document to the Wine environment where any Windows virus will be able to munge it. You simply cannot have it both ways.
What is it with you people? I was just trying to make a point about the security risks about using wine at present. And you start flameing me? Instead of continuing this flame war I will try to express myself more clearly.
Before I go into details of my idea, lets make a few things clear... I agree that focus of the Wines project, should be more towards running windows applications than on extreme security. I also agree that securing an environment usually means reducing the freedom and flexibility to do things. My intention was that some security should be offered in wine regarding the attacks. This would not neccesary need to be a mandatory solution, it should IMHO be an easily configured on/off option feature.
My idea is to use ptrace in a supervisor process to trap all syscalls from the wine process, and use some kind of sanity checks for some of the syscalls. Watching the fork,exec,open,write and unlink syscalls and doing sanity checks could offer atleast some security.
Could this work? Do you see this as a useful option?
//Peter
On Sunday 27 October 2002 03.06, Francois Gouget wrote:
On Sun, 27 Oct 2002, Peter Andersson wrote: [...]
I believe most wine users trust wine not to touch anything outside of its configured drive space. Malicious Linux/Unix syscalls could be embedded in windows apps and if executed do a great deal of damage. After all checking your app is run whithin Wine is not that hard (reading registry settings for instance). Lets call such an malicious app a wine-virus from now on. At present a wine-virus would even be allowed to fork itself, leaving the wine environment and continue to run even after you shutdown the wineserver, and in some cases even after the user logs out. The virus would now have full access to the system whithin the users permission, doing much greater damage than you expected.
The question is...Would you expect that damage from running a windows app in wine, when you know it could be safely run in Windows? In just a few embedded bytes in the code it could remove your home directory in a single syscall. Would you expect that? - I wouldnt.
[...more snipped...]
Certainly I would be surprised to see a Wine-aware virus tomorrow. In that sense I certainly would not expect this sort of thing to happen tomorrow. But you seem to be confused about the goal of Wine.
The goal of Wine is to run Windows applications on Unix. Windows applications run through Wine should be able to do no more and no less than any other Linux application. Thus Wine is not more of a security risk than any other piece of (somewhat alpha) software.
But the goal of Wine is *not* to build a sandbox or a virtual machine in which you can safely run malicious code. If that is what you want, then you should look at chroot, jail, User Mode Linux, VMWare or Plex86. You can even combine them with Wine to build sandboxes. For instance you could run Wine in a 'jail' environment and then a Wine-aware would be confined to that environment.
That being said, yes it is possible to configure Wine such that Windows applications are confined to a small portion of your disk. It is a useful feature and, as far as I know, it should work against all current Windows viruses. Of course, when configured this way Wine is not very useable. You would not be able to use Word to edit your documents for instance... that is unless you menually copy the document to the Wine environment where any Windows virus will be able to munge it. You simply cannot have it both ways.
On Sun, 27 Oct 2002, Peter Andersson wrote:
What is it with you people? I was just trying to make a point about the security risks about using wine at present. And you start flameing me? Instead of continuing this flame war I will try to express myself more clearly.
You call that a flame?
/Johan Gill, johane@lysator.liu.se
On Sunday 27 October 2002 11:37, Peter Andersson wrote:
What is it with you people? I was just trying to make a point about the security risks about using wine at present. And you start flameing me?
I don't see any flames, just strong criticism of your idea for which you may not have thought all the issues through. WINE is not a sandbox as Alexandre pointed out, because writing a sandbox for any system is hard work: as proof look at the complexity of Valgrind, a program which emulates an x86-Linux system on top of another x86-Linux system for diagnostic purposes. Think how much harder it is to write the same kind of code for an OS when you've not got the same OS under your feet; it would be a slow-performing monster of a program.
Given that WINE is not a sandbox, simplistically it's a translator of system calls & binary formats, the risks of running a WINE-based program are exactly the same risks you run with any unknown binary code, so any checks on sanity of syscalls are better done in the kernel or general-purpose executable wrapper than in WINE specifically.
I started a conceptually similar emulator project to WINE a while ago for another OS (riscose.sf.net): a program to run RISC OS binaries on Unix. The issues are the same: just because malicious code comes from an unfamiliar OS doesn't make its destructive capabilities any different from native code, so if you're looking to tighten security of WINE programs, look to the same methods you'd use to tighten security of *any* unknown program: run it as a different user, run it in a Usermode Linux instance (user-mode-linux.sf.net), use kernel patches to restrict its use of system calls. But WINE shouldn't be bothered with any of this.
If you're interested in playing with this kind of work, I know someone has written a Python-based framework (called Subversion or Subterfuge or something like that, sorry, can't find a link...) which lets you run any Linux process with bits of Python code intercepting and changing or barring system calls on the fly. That could be used to prototype a much more general Linux security framework, and one that could be used for more projects than just WINE.
cheers,
On October 27, 2002 06:37 am, Peter Andersson wrote:
My idea is to use ptrace in a supervisor process to trap all syscalls from the wine process, and use some kind of sanity checks for some of the syscalls. Watching the fork,exec,open,write and unlink syscalls and doing sanity checks could offer atleast some security.
Peter, You have not been flamed. Yet. But if you continue in this maner, you will. Really, the idea is silly. There is no 'security' issue. What you're talking about is nonsensical. So it would be a lot more productive to contemplate why this is so, rather than repeating the same stuff, over, and over.
Could this work?
No.
Do you see this as a useful option?
Absolutely not.
The idea is so 'out there' that's almost hard to argue against it. Instead of 'some kind of sanity checks for some of the syscalls', please give us _ONE_ example of what those 'some's are. That is, describe an example of one sanity check, in one syscall. And we'll then tell you why that makes no sense.
On Sun, 27 Oct 2002, Peter Andersson wrote:
What is it with you people? I was just trying to make a point about the security risks about using wine at present. And you start flameing me?
We're not flaming you. We're just see big flaws with your proposal. We also proposed alternatives that seem to make more sense to us.
Why don't you study how chroot or jail could be used in combination with Wine to build a sandbox? As far as I know no-one has tried that and it is possible that some changes in Wine could make things simpler to set up. Of course, we won't know until someone actually tries this.
Also, I'm told that jail (available on FreeBSD) is much better than chroot. chroot only restricts access to files while I believe jail can also restrict access to other running processes and other system resources. Unfortunately I don't think a jail-like functionality is implemented on Linux. If you were to implement this I'm sure countless people would be grateful.
http://docs.freebsd.org/44doc/papers/jail/jail.html
Finally you could wrap it up by writing scripts that would make it easy to run Wine in a sandbox, and restore the sandbox to a clean state after a program has been run.
On Sunday 27 October 2002 22.19, Francois Gouget wrote:
On Sun, 27 Oct 2002, Peter Andersson wrote:
What is it with you people? I was just trying to make a point about the security risks about using wine at present. And you start flameing me?
We're not flaming you. We're just see big flaws with your proposal. We also proposed alternatives that seem to make more sense to us.
Why don't you study how chroot or jail could be used in combination with Wine to build a sandbox? As far as I know no-one has tried that and it is possible that some changes in Wine could make things simpler to set up. Of course, we won't know until someone actually tries this.
Finally someone that takes my concerns serriously, thank you!
I agree. Using chroot could offer the functionality Im looking for.
I will try the chroot model for now, I have a feeling that this wont be enough though, but we will see. Something in the chroot manside got me puzzled:
... ... ... Only the super-user may change the root directory.
Note that this call does not change the current working directory, so that `.' can be outside the tree rooted at `/'. In particular, the super-user can escape from a `chroot jail' by doing `mkdir foo; chroot foo; cd ..'. ... ... ...
I will have to figure out the consequences of this odd behaviour, it certainly dont sound very safe at first look. Maybe jail is much better, but it seems to require porting as you said.
//Peter
On Sun, 27 Oct 2002, Peter Andersson wrote: [...]
I agree. Using chroot could offer the functionality Im looking for.
I also saw this today on kernel-traffic. It looks pretty much like what you are looking for:
* Linux Security Protection System http://www.uwsg.indiana.edu/hypermail/linux/kernel/0210.2/0123.html
From the announcement:
...
Filesystem Access Domain subsystem allows restriction of accessible filesystem parts for both individual users and programs. Now you can restrict user activities to only its home, mailbox etc. Filesystem Access Domains works on device, dir and individual file granularity.
IP Labeling lists enable restriction on allowed network connections on per program basis. From now on, you may configure your policy so that no one except your favorite MTA can connect to remote port 25
...
So using these features plus some wrapper scripts around Wine, it should be possible to prevent Windows applications from going where they are not allowed.
On Mon, 28 Oct 2002, Francois Gouget wrote:
On Sun, 27 Oct 2002, Peter Andersson wrote: [...]
I agree. Using chroot could offer the functionality Im looking for.
I also saw this today on kernel-traffic. It looks pretty much like what you are looking for:
- Linux Security Protection System http://www.uwsg.indiana.edu/hypermail/linux/kernel/0210.2/0123.html
This seems to be a popular theme these days. Here's yet another one:
* Rule Set Based Access Control http://www.uwsg.indiana.edu/hypermail/linux/kernel/0210.2/2128.html http://www.rsbac.org/
They say it supports Jail-like functionality with extensions but the 'Role Compatibility' may be useful too.
P. Christeas wrote:
Write a segment of code that will abort wine, if it is run as root (that is, just before wine starts anything). This piece of code should only be explicitly disabled in the 'configure' script. That way, only a
I slightly disagree - I think the thing to do would be to have wine not run if UID == 0, UNLESS the commandline parameter --i-know-i-am-root is set, AND THEN pop up a dialog box that requires confirmation before continuing.
I would ALSO suggest that wine check the execute bit on the application being run - the recent incident with Klez running under Wine would not have happened (I think) if wine would not run that which is not marked with the -X bit (unless, again, a command line parameter is supplied, and a warning dialog is confirmed).
Since I know of no mail client for Linux that would set the X bit on an attachment, this would help protect users from themselves, while allowing those that need to be able to take the risks to do so.
And as for making "/" available as a Wine drive - how about creating a tool that would allow you to add or remove drive mappings at run time? So that if I find that I really do need /usr/foo/bar/baz available to Wine, I can run a program that tells wineserver to add that as drive Q: for now.
"David D. Hagood" wrote:
P. Christeas wrote:
Write a segment of code that will abort wine, if it is run as root (that is, just before wine starts anything). This piece of code should only be explicitly disabled in the 'configure' script. That way, only a
I slightly disagree - I think the thing to do would be to have wine not run if UID == 0, UNLESS the commandline parameter --i-know-i-am-root is set, AND THEN pop up a dialog box that requires confirmation before continuing.
I would ALSO suggest that wine check the execute bit on the application being run - the recent incident with Klez running under Wine would not have happened (I think) if wine would not run that which is not marked with the -X bit (unless, again, a command line parameter is supplied, and a warning dialog is confirmed).
Since I know of no mail client for Linux that would set the X bit on an attachment, this would help protect users from themselves, while allowing those that need to be able to take the risks to do so.
And as for making "/" available as a Wine drive - how about creating a tool that would allow you to add or remove drive mappings at run time? So that if I find that I really do need /usr/foo/bar/baz available to Wine, I can run a program that tells wineserver to add that as drive Q: for now.
It should not be that easy. We can all understand that the 'klez' case wouln't have happened if wine had properly been configured. Windoze users are used to press 'OK' to all dialogs and grant privileges to any program asking for them. There is no practical reason a regular user would want to run Wine as root. That's what the *nix security model is all about. Wine developers should make sure there is no such need. The same applies for files. There is no reason a wine user would want to read/write protected files. If we make config available (the way you described it), wrong settings are bound to be made. We are just securing wine from its users.
I slightly disagree - I think the thing to do would be to have wine not run if UID == 0, UNLESS the commandline parameter --i-know-i-am-root is set, AND THEN pop up a dialog box that requires confirmation before continuing.
does rm have such an option ? rm doesn't, so I don't see any reason for this code bloat if you want to be paranoid (or you distro want to be), do it in wine script (or in the .winewrapper extension)
I would ALSO suggest that wine check the execute bit on the application being run - the recent incident with Klez running under Wine would not have happened (I think) if wine would not run that which is not marked with the -X bit (unless, again, a command line parameter is supplied, and a warning dialog is confirmed).
that could bring some issues while trying to run a native executable from a mounted FAT driver (without the proper umask option for mount) (this could be circumvented by a drive configuration option in wine, but that would be a bit tricky to set for the average user)
Since I know of no mail client for Linux that would set the X bit on an attachment, this would help protect users from themselves, while allowing those that need to be able to take the risks to do so.
IMHO (regarding Klez), the main issue is the mail client not wine. It should protect/warn the user about this, not forward the blame on others
And as for making "/" available as a Wine drive - how about creating a tool that would allow you to add or remove drive mappings at run time? So that if I find that I really do need /usr/foo/bar/baz available to Wine, I can run a program that tells wineserver to add that as drive Q: for now.
I think this a more interesting alternative. People did start working on that (especially for SMB shares mounting) A+
Excuse me, but I don't think that any of these proposed methods will live up to any real malicious code. Personally, I believe we should make wine: A. Not require root B. As secure on it's own as possible (i.e. - not open to any problems not introduced by the hosted program).
These two should allow securing Wine to the point where it is up to the packagers and to the people calling Wine to do their tasks, giving them the tools to do so. I don't believe we should, or even that we CAN, solve security problems introduced by insecure deployment.
The only thing is that we should make secure deployment as easy as possible, not that we should make insecure deployment impossible. The later is both unobtainable, and will hurt usability.
Shachar
David D. Hagood wrote:
P. Christeas wrote:
Write a segment of code that will abort wine, if it is run as root (that is, just before wine starts anything). This piece of code should only be explicitly disabled in the 'configure' script. That way, only a
I slightly disagree - I think the thing to do would be to have wine not run if UID == 0, UNLESS the commandline parameter --i-know-i-am-root is set, AND THEN pop up a dialog box that requires confirmation before continuing.
I would ALSO suggest that wine check the execute bit on the application being run - the recent incident with Klez running under Wine would not have happened (I think) if wine would not run that which is not marked with the -X bit (unless, again, a command line parameter is supplied, and a warning dialog is confirmed).
Since I know of no mail client for Linux that would set the X bit on an attachment, this would help protect users from themselves, while allowing those that need to be able to take the risks to do so.
And as for making "/" available as a Wine drive - how about creating a tool that would allow you to add or remove drive mappings at run time? So that if I find that I really do need /usr/foo/bar/baz available to Wine, I can run a program that tells wineserver to add that as drive Q: for now.
On Sun, Oct 27, 2002 at 07:51:01AM -0600, David D. Hagood wrote:
I would ALSO suggest that wine check the execute bit on the application being run - the recent incident with Klez running under Wine would not have happened (I think) if wine would not run that which is not marked with the -X bit (unless, again, a command line parameter is supplied, and a warning dialog is confirmed).
Broken idea. This would stop any and all installers, as they first extract a compressed archive and then invoke *further* install helper programs. Windows is not Unix, period. That's why mapping to the X bit really doesn't make sense IMHO.
On Sun, 27 Oct 2002, David D. Hagood wrote:
P. Christeas wrote:
Write a segment of code that will abort wine, if it is run as root (that is, just before wine starts anything). This piece of code should only be explicitly disabled in the 'configure' script. That way, only a
I slightly disagree - I think the thing to do would be to have wine not run if UID == 0, UNLESS the commandline parameter --i-know-i-am-root is set, AND THEN pop up a dialog box that requires confirmation before continuing.
I don't think this is necessary.
Either the user is already logged in as root, as in 'I typed root when XDM asked me my login' (or the system logged me in as root like in Lindows), and then he has more important things to worry about.
Or he logged in as a regular user and su-ed as root and is now running a Wine application. If he took the pain to su as root (and adjust $DISPLAY and permissions appropriately), then I would trust him to know what he is doing. Windows users don't su as root (they use the KDE/Mandrake/etc menu entries that automatically ask for the root password).
Anyway, this idea is so trivial to implement in the Wine wrapper (a shell script) that it is really not an issue, and can be left to packagers (to add or remove).
I would ALSO suggest that wine check the execute bit on the application being run - the recent incident with Klez running under Wine would not have happened (I think) if wine would not run that which is not marked with the -X bit (unless, again, a command line parameter is supplied, and a warning dialog is confirmed).
As someone else pointed out this would break a lot of programs.
But there is an interesting aspect that I did not see mentioned before. The user reporting this says he was using KMail. I did some tests with KMail and whenever you open an attachement you get a warning that it may compromise your security. This may sound good but this happens for every single attachement: for text attachements, diff files, gifs, jpgs, everything. And this is a rule of security: if security measures get in the way they will be ignored. Here I'm sure KMail users just get the reflex of systematically clicking on Open don't even read the message after the first couple of times. To improve security KMail should issue warnings in a more discriminate manner (have a (user-configurable) list of known safe MIME types for instance).
[...]
And as for making "/" available as a Wine drive - how about creating a tool that would allow you to add or remove drive mappings at run time? So that if I find that I really do need /usr/foo/bar/baz available to Wine, I can run a program that tells wineserver to add that as drive Q: for now.
Again many people said Wine should not be configured to have access to your home directory or to /. But this would be a big usability problem and make Wine useless for all people using Wine in an office environment. In such an environment people need to open Word documents sent as attachement by collegues (/tmp/...), located on a file server (/mnt/server/....), or documents they work on ($HOME/...). Remove the drives that let them access these documents and Wine becomes so cumbersome to use that it is unusable.
In fact, arguing for the removal of these drives is a bit similar to arguing that Emacs should be run in a chroot-ed environment to protect you from malicious Lisp programs. Of course it means that you would have to copy files back and forth to edit them and thus no one is advocating that.
Eric Pouech wrote:
does rm have such an option ? rm doesn't, so I don't see any reason for
Actually, rm DOES have such an option: -i, --interactive prompt before any removal
AND certain distros (RedHat for example) alias rm to "rm -i" by default.
Also, I stated that the command line parameter to wine would be required to even start the process - in other words, if you didn't supply it, you would not get the dialog, wine would just terminate.
AND, this would not necessarily have to be bloat in wine, it could be handled by a default wrapper - the wrapper checks UID and command flags, provides feedback if Wine needs to rebuild the font cache, etc.
You represent one extreme of the spectrum - "This isn't Wine's job, we shouldn't do anything."
The other side - "Wine should be safe. If things aren't safe, don't run", has also been represented here.
I'm just suggesting a middle ground.
Also, I stated that the command line parameter to wine would be required to even start the process - in other words, if you didn't supply it, you would not get the dialog, wine would just terminate.
AND, this would not necessarily have to be bloat in wine, it could be handled by a default wrapper - the wrapper checks UID and command flags, provides feedback if Wine needs to rebuild the font cache, etc.
that's what I suggested in my previous mail: 1/ don't do it inside wine binary 2/ if you really want to do it, do it from the wrapper (which is also well suited for distros specific configuration options)
You represent one extreme of the spectrum - "This isn't Wine's job, we shouldn't do anything."
my point is: there is enough ways to do it (inside wine, inside linux...) to not need to add more stuff to wine binaries. what may lack indeed is the proper documentation (for packagers...)
A+
Geoff Thorpe wrote:
On Thursday 31 Oct 2002 10:00 am, Greg Turner wrote:
On Thursday 31 October 2002 08:10 am, Raul Dias wrote:
My $0.02,
A way to make it more secure is to catch key API calls and decide if the application is allowed to run it or not.
not a bad idea.
Wine could implement a clean Security Layer: YES
Clean, perhaps, but secure? That depends on what you are trying to achieve: since the unix API is available to apps running under wine,
This subject interests me a great deal so please humour me as I try to wrap my head around the wine-specifics well enough to get an accurate(ish) picture of this. I'm a security person, but no win32 expert and even less of a PE/ELF hacker...
First I can understand the point made that, at the end of the day, the only *actual* security you can force on a wine-loaded application is whatever security the operating system forces on *all* applications (wine-loaded or otherwise) running as the same user. Ie. even if a win32 application loaded under wine couldn't directly call ioctl(), unlink(), or fopen(), the binary code could still *reimplement* those functions in assembly. I also realise that other assembly hacks (or just trail-and-error "luck" virii) could scan the process's memory space looking for likely function pointers, file-descriptors, etc and start meddling with them directly to bypass the wine-implemented win32 API. Does that seem a reasonable understanding of the situation?
My next question is this: why is the unix API available to wine-loaded PE apps/libs? I can't see a single compelling reason for this, though I'm prepared to be illuminated otherwise. If we discard memory-scanning and other assembly tricks for a moment and consider just the case of PE apps/libs generated from "clean C" (and "clean compilers"); then preventing any direct binding of any wine-loaded PE images to native ELF images, *except* those implemented by wine, immediately raises the bar. Of course, I'm assuming this is *possible* with the PE (and ELF) format(s)?
My problem with discarding the "clean" security layer because it isn't perfectly impenetrable in a technical sense, is that it is purely an abstract technical-only view of things, and Wine's role (and threat-model for its future success) is anything but purely technical. Jeremy, I'd be particularly interested if you have any thoughts on this. AFAICS, this idea is not just a question of security by obscurity - there are technical and "political" issues involved too.
First, not linking PE images to non-wine ELF images allows one to define a security policy in wine for win32/PE executable code akin to a "rules for Win32 programs" config. One possibility here is the kind of thing Raul was discussing. Buggy programs aren't programs that try to detect if they're running in wine and if so do damage - buggy programs are programs using the win32 API written by careless win32 bunnies. *Those* programs could be subject to a policy configuration that would allow you to selectively restrict things in a way that will *always* be better than what MS-windows provides - whether the programs are horribly buggy or really solid. In other words, a configurable real-world control/protection against potentially buggy win32 code (that would be equally buggy on MS-windows and Wine after all).
Second, if the PE loader doesn't blindly link PE apps/libs to native libraries, then bypassing the wine-implemented win32 API (and thus the policy configuration) would require an *explicit* workaround on the part of the programmer. Putting in assembly code to prime registers and fire interrupts that (a) on linux would getenv("HOME") and unlink() the result, and (b) on windows would probably just crash with a BSOD is what the security community call a "virus". :-) It doesn't have to be difficult for the programmer to do it, it just has to require him/her to be malicious and unambiguously *intend* to do it. Writing and distributing one of these things opens you up to criminal prosecution in many jurisdictions, and also allows McAfee and friends to assign a signature to corresponding binaries and get them classified as a virus (and their authors classified as bad people).
Or put another way - as Wine converges on "beta" or "release" level and Wine + XXX/OS (where XXX=Linux,FreeBSD,etc) becomes not only a competitor to MS-windows, but in fact offers considerable advantages, where then will the *threats* to wine lie?? I would certainly like to (a) see the flexibility of being able to apply a "soft" security policy for win32 applications in the wine-implemented win32 API, (b) force win32 developers who are "anti-wine" and "pro-monopoly" to have to expose themselves to criminal possibilites if they want to bypass wine-based execution configuration and controls (or worse, if they want to package anti-wine trojans).
So, for example, this could be used to protect a system against security flaws in Internet Exploder or Outlook... but a malicious virus writer could work around winapi-based security provisions, as discussed earlier in this thread.
Yes, and I think the point that's worth making is that writing a malicious virus against wine is not only a crime in the sense that normal virus-writing is a crime, but also has anti-trust/anti-competition overtones ... when you try to imagine which companies would most like their win32-based applications to *NOT* run on wine (and perhaps even hurt wine users), you might understand where I'm coming from.
In lieu of "pure" security enforcements (which would require virtualisation anyway which Wine is not in the business of), I think a "win32-API-based" security approach is worthwhile. If I can write win32 apps that link directly to libc, I could elect to replace the file-management subsystem of my app with a POSIXy layer that is only used on wine "for performance reasons only, honest!". This would mean (a) Wine's file-system configuration can be bypassed, and (b) I could (perhaps deliberately) embed nasty corruption bugs in my POSIX subsystem but have my win32 subsystem very stable. This program would just be "unstable on wine" but not "anti-competitive" nor "criminal". But if you don't let applications do this in wine's PE-loader (or at least let it be controllable in the config) then acheiving the same result would require me to write a genuine virus instead (and so open myself to anti-trust/criminal accusations).
Thoughts?
Cheers, Geoff
I think this is missing the point. The way to make something secure isn't to make big software companies worry about anti-trust, or virus writers worry they might get sued for writing a virus. Big companies aren't likely to write wine-specific special workarounds that do nasty things, and virus writers couldn't care less. Any security improvements should be normal UNIX ideas like letting a wineserver do certain priviledged tasks running as a special user, while standard wine programs run as a different, non-priviledged user. In other words, the kernel layer in Windows should have higher priveledges than standard user processes, but not run as root.
David
Hi there,
On Thursday 31 Oct 2002 2:21 pm, David Fraser wrote:
I think this is missing the point.
No, I think you're stuck on a point that wine is simply destined (ie. as in "fate") to miss on both our behalves. I'm talking about a different point where some useful headway could be made.
The way to make something secure isn't to make big software companies worry about anti-trust, or virus writers worry they might get sued for writing a virus. Big companies aren't likely to write wine-specific special workarounds that do nasty things, and virus writers couldn't care less.
This is an opinion stated as fact, and I don't understand how this is relevant to the points I made.
Any security improvements should be normal UNIX ideas like letting a wineserver do certain priviledged tasks running as a special user, while standard wine programs run as a different, non-priviledged user. In other words, the kernel layer in Windows should have higher priveledges than standard user processes, but not run as root.
I don't know exactly how the roles are divided up in the wineserver protocol, but for your suggestion to actually work naturally using "normal UNIX ideas", you would need to inverse the sense of the privilege separation. Ie. wine programs (and loaders, etc) would have to run as a special user ("nobody" perhaps) and to have the wineserver run as the "normal user". Otherwise, how else will you have win32 application behaviour integrate sanely with the native UNIX permissions?
However, that still *requires* that the wineserver is actually doing all the work and the wine processes that load and link PE images are doing very little except marshalling the win32 API back and forth to the wineserver. I'm not convinced that's the case but would be thrilled to find out if it was. Ie. does wineserver handle all translation from win32 to native? GUI? network? file-system? Or does some "permission-sensitive" functionality translation happen directly from the PE-loaded processes by way of some linking-in of Wine's win32 implementation? I fear the latter, if for no other reason that the performance would probably suck if *everything* was marshalling back and forth to wineserver. If so, this makes privilege separation no more secure than what I suggested but a lot more hassle.
So if the PE-loaded executables need to run as your "normal" user to have any meaningful/useful functionality, then you're stuck back with the comments I made in my previous post. Admittedly they don't construct a (impenetrable except through wine bugs) "secure" wall against any PE-payloaded anti-wine virus, but (a) this does prevent "regular" (non-trojan) PE images from misbehaving on wine in ways they wouldn't misbehave on MS-windows, and (b) it lets wine exercise a far more flexible, fine-grained, and extensible configuration over how win32-based applications behave - better than you can get in any MS version of windows, and in fact better in many ways that you can get with native applications on Linux/****BSD/etc ;-)
Eg. imagine if I could specify a flag when executing wine that would "stick" a label to all subsequent wine processes - eg. if I run;
$ wine --sticky=WEB "C:\...\iexplore.exe"
then my wine configuration could specify extra restrictions for the "WEB" label (only allow network access on TCP/IP to address 'squid.localnet', only allow write access to certain fixed directories, prompt the user if it tries to open new windows, etc). This is the sort of thing I mean - you can't even do it in MS windows. You could also set up "special" root-like behaviours - eg. if you want to run IIS to listen on port 80 and 443 (something only root can do in *nix), you could set up a wine configuration such that it would (a) report an error unless you start it as root, (b) create sockets bound to ports 80 and 443, (c) change back to the "normal" user, (d) intercept any future win32 calls that try to create listening sockets on 80 and 443 and let them use the ones it already created. The possibilities are obviously wide-open and I'm not necessarily suggesting any of the above should be implemented in that form - but I certainly think having Wine's PE-loader let win32 applications bind directly to native libraries (glibc for example) make the security and flexibility elements of all this disappear quite quickly.
Cheers, Geoff
On Thu, 31 Oct 2002, Geoff Thorpe wrote:
However, that still *requires* that the wineserver is actually doing all the work and the wine processes that load and link PE images are doing very little except marshalling the win32 API back and forth to the wineserver. I'm not convinced that's the case but would be thrilled to find out if it was. Ie. does wineserver handle all translation from win32 to native? GUI? network? file-system?
The wineserver doesn't do any GUI as such, but it does handle message queues. It's also responsible for handling win32 requests for opening files and creating network sockets. Win32 security is meant to go into the wineserver (if ever), so the model is already close to what you want, I guess.
Or does some "permission-sensitive" functionality translation happen directly from the PE-loaded processes by way of some linking-in of Wine's win32 implementation?
Maybe some, but no fundamental ones, I think. Any such could probably easily be rewritten.
I fear the latter, if for no other reason that the performance would probably suck if *everything* was marshalling back and forth to wineserver.
It did, before Alexandre made some improvements (like shared memory and caching of file handles). It still does in some cases. But there are reasons other than security (like Windows's crappy IPC model) why everything must go through the wineserver, so it was a necessary evil (yet not so evil if it can help security, I guess)
I'm not necessarily suggesting any of the above should be implemented in that form - but I certainly think having Wine's PE-loader let win32 applications bind directly to native libraries (glibc for example) make the security and flexibility elements of all this disappear quite quickly.
What do you mean? No PE apps can link straight to glibc. Only Unix-implemented DLLs (like the Wine ones) can link to it. The problem is rather that glibc will still be loaded into the process's *address space*, and thus a bad app could then get to it by searching for it in memory or get to it through the Wine builtin DLLs.
Hi there,
On Friday 01 Nov 2002 8:23 am, Ove Kaaven wrote:
On Thu, 31 Oct 2002, Geoff Thorpe wrote:
However, that still *requires* that the wineserver is actually doing all the work and the wine processes that load and link PE images are doing very little except marshalling the win32 API back and forth to the wineserver. I'm not convinced that's the case but would be thrilled to find out if it was. Ie. does wineserver handle all translation from win32 to native? GUI? network? file-system?
The wineserver doesn't do any GUI as such, but it does handle message queues. It's also responsible for handling win32 requests for opening files and creating network sockets. Win32 security is meant to go into the wineserver (if ever), so the model is already close to what you want, I guess.
Not too far by the sounds of things - still if the PE-loaded process is the one creating and controlling windows there become permission difficulties running it as a "nobody" user (and assembly hacks in the PE-executables could still try to do nasty crap in an anti-wine fashion if it has rights to your X-server). But at least this seems to provide for file-system and network policy enforcement by the wineserver process.
Or does some "permission-sensitive" functionality translation happen directly from the PE-loaded processes by way of some linking-in of Wine's win32 implementation?
Maybe some, but no fundamental ones, I think. Any such could probably easily be rewritten.
Cool.
What do you mean? No PE apps can link straight to glibc. Only Unix-implemented DLLs (like the Wine ones) can link to it. The problem
Ah, this had been my question. It seemed otherwise from the earlier post I had seen. I'm glad this is the case - you need to use virus-style hacks if you want your PE app to bypass (or corrupt) the interfaces provided by Wine libraries.
is rather that glibc will still be loaded into the process's *address space*, and thus a bad app could then get to it by searching for it in memory or get to it through the Wine builtin DLLs.
I understand the memory-scanning possibilities (just being able to find and corrupt wine-sensitive data is enough). However, if you sandbox those wine processes as a "nobody" user anyway, then any genuine attempts to bypass the wineserver-enforce policies would become a lot more difficult, ie. you'd be restricted to communicating with the wineserver and trying to convince it to do your nasty stuff for you. This is about the same problem as writing nasty code for MS windows. Moreover, the PE-loaded app doesn't get to execute its own code in the wineserver does it? If so, there's some merit to the approach David suggested.
So essentially I guess we could specify, for example, that no wine-loaded application has access to "F:" unless it is enabled in the wine command-line arguments? Eg.
wine --config-section=enable-F-home C:\...
where 'enable-F-home' could be a section in the config file specifying to map F: to $HOME?
IIUC, the answer to my PE-linkage question means the wineserver can enforce such rules unless the PE app uses "nasty" workarounds (eg. memory scanning assembly hacks)? The other answer you gave me suggests that if the PE apps could run in "nobody"-jailed processes, then there is even some protection against nasty workarounds (ie. the file-system and network policies become more genuinely, and less "voluntarily", secure)?
Cheers, Geoff
Le ven 01/11/2002 à 11:27, Geoff Thorpe a écrit :
Hi there,
[snip]
What do you mean? No PE apps can link straight to glibc. Only Unix-implemented DLLs (like the Wine ones) can link to it. The problem
Ah, this had been my question. It seemed otherwise from the earlier post I had seen. I'm glad this is the case - you need to use virus-style hacks if you want your PE app to bypass (or corrupt) the interfaces provided by Wine libraries.
No. Just launch a Winelib app from the PE (it must be permissible to do so), and that Winelib app then has access to glibc and friends, and can act as a gateway between the main app and the outside (the sandbox) world. That app could be meant as an "enhancement" or "workaround" when running under Wine (thus not affecting normal Windows operation), but still have a "bug" which can do nasty things.
is rather that glibc will still be loaded into the process's *address space*, and thus a bad app could then get to it by searching for it in memory or get to it through the Wine builtin DLLs.
I understand the memory-scanning possibilities (just being able to find and corrupt wine-sensitive data is enough). However, if you sandbox those wine processes as a "nobody" user anyway, then any genuine attempts to bypass the wineserver-enforce policies would become a lot more difficult, ie. you'd be restricted to communicating with the wineserver and trying to convince it to do your nasty stuff for you. This is about the same problem as writing nasty code for MS windows. Moreover, the PE-loaded app doesn't get to execute its own code in the wineserver does it? If so, there's some merit to the approach David suggested.
So essentially I guess we could specify, for example, that no wine-loaded application has access to "F:" unless it is enabled in the wine command-line arguments? Eg.
wine --config-section=enable-F-home C:\\...where 'enable-F-home' could be a section in the config file specifying to map F: to $HOME?
Remember (from the thread on 0.8.0 feature list) that the config file should be merged completely in the registry, with a control-panel like app to aaply changes. So at least that app will need to be able to access it read/write.
IIUC, the answer to my PE-linkage question means the wineserver can enforce such rules unless the PE app uses "nasty" workarounds (eg. memory scanning assembly hacks)? The other answer you gave me suggests that if the PE apps could run in "nobody"-jailed processes, then there is even some protection against nasty workarounds (ie. the file-system and network policies become more genuinely, and less "voluntarily", secure)?
Is it even possible to switch to the nobody user without having higher priviledges beforehand? I thought you needed to be launched by root (or SUID root, etc.) to switch to nobody, since it can't login (su, ssh, etc.)
Cheers, Geoff
-- Geoff Thorpe geoff@geoffthorpe.net http://www.geoffthorpe.net/
Just my 0.02 $ (yes, $ after. Do you say "dollar 3.56"? Neither do we in French :)
Vincent
On Friday 01 Nov 2002 11:51 am, Vincent Béron wrote:
Le ven 01/11/2002 à 11:27, Geoff Thorpe a écrit :
Hi there,
[snip]
What do you mean? No PE apps can link straight to glibc. Only Unix-implemented DLLs (like the Wine ones) can link to it. The problem
Ah, this had been my question. It seemed otherwise from the earlier post I had seen. I'm glad this is the case - you need to use virus-style hacks if you want your PE app to bypass (or corrupt) the interfaces provided by Wine libraries.
No. Just launch a Winelib app from the PE (it must be permissible to do so), and that Winelib app then has access to glibc and friends, and can act as a gateway between the main app and the outside (the sandbox) world. That app could be meant as an "enhancement" or "workaround" when running under Wine (thus not affecting normal Windows operation), but still have a "bug" which can do nasty things.
In what way is that different from what I said? It's a wine-specific work-around - the winelib app you invoke is either wine-provided (ie. not a problem) or a wine-specific payload your application is carrying. This is equivalent to embedding assembly hacks (after all, your assembly hacks could be a complete winelib app image that you save to a file and execute).
I don't see the issue of executing winelib apps as a fundamental security problem as such - for example, what if your policy says not to load executables or libraries from "C:\" unless they're PE format? Likewise, what is to stop you defining a policy that wineserver-managed applications can't execute winelib apps unless they're (a) provided by wine (/usr/lib/wine/... and not C:\...), or (b) you've specifically granted them rights to do so.
The point remains that to do damage, applications have to implement very deliberate wine-targetted workaround measures if they don't want to be subject to policies configured by the user (and enforced by wineserver). By "deliberate", I mean they have to detect the wine environment (memory scanning, "signature" characteristics of unimplemented or buggy win32 API functions, etc) before then delivering their "special" payload. Ie. they have to write anti-wine viruses. Moreover, jailing the non-wineserver processes (if possible) to a "nobody" user makes it *possible* to provide some actual protection against such untrusted PE win32 apps. Not that *possible* means *default* of course :-)
OTOH: If an application is written to have wine-specific functionality and you want to accept it, that's something you could support. Kind of like turning MS's "embrace and extend" policy against themselves - allow applications to support Wine-specific enhancements that can't be used in MS windows. But in this situation, you're trusting and accepting both win32 *AND* native code - and you're not any more exposed than if you were just trusting a native application.
My point against anti-wine measures, I think, remains. If you are forced to run untrusted (ie. potentially anti-wine) binaries, there seems to be a lot that can be done on two levels; first, forcing anti-wine measures to be explicit payload-bearing virii and not just annoying "features". Second, jailing PE-loaded code with user privileges so that only the wineserver has all the native (unix) permissions of your regular user account. The first is a criminal (and complexity) deterrent. The second is an actual hardening of wine's security model.
So essentially I guess we could specify, for example, that no wine-loaded application has access to "F:" unless it is enabled in the wine command-line arguments? Eg.
wine --config-section=enable-F-home C:\\...where 'enable-F-home' could be a section in the config file specifying to map F: to $HOME?
Remember (from the thread on 0.8.0 feature list) that the config file should be merged completely in the registry, with a control-panel like app to aaply changes. So at least that app will need to be able to access it read/write.
Doesn't the wineserver process handle all registry manipulation? If so, the wineserver doesn't even have to let the applications get file-access to the registry - but either way, if it's the wineserver, you can implement a policy however you like without worrying about nasty workarounds embedded in the PE images. That policy could be an "override the registry settings in situation XXX" type of thing, or simply built in to the registry configuration model (the wineserver would just have to refuse to manipulate those entries if asked to by (untrusted) applications). You could even write a win32 configuration GUI that would manipulate these entries, then set your policy to allow *only* that application to touch them.
Is it even possible to switch to the nobody user without having higher priviledges beforehand? I thought you needed to be launched by root (or SUID root, etc.) to switch to nobody, since it can't login (su, ssh, etc.)
There is always a way :-) You could chmod 4755 the wine binary and wine itself could setuid back down to the "regular" user when initialising the wineserver and could setuid down to "nobody" when initialising the PE-loader. By the way, processes started as root that drop use privileges (on most posixy systems) become very hard to run memory scanning attacks and a variety of other things an anti-wine virus writer would find useful (it's also harder to attach a debugger to). If the wineserver needs to be able to create extra "nobody" processes later then there's probably a different way of doing this - eg. make the PE-loader be a chmod 4755 binary so it can start as root and fold down to "nobody" - then it can be invoked by the "normal" user, including the wineserver process(es).
Just my 0.02 $ (yes, $ after. Do you say "dollar 3.56"? Neither do we in French :)
moi non-plus en anglais - mais c'est surement "0,02 $", non? :-)
Cheers, Geoff
-
Alexandre Julliard -
Andreas Mohr -
David D. Hagood -
David Fraser -
Dimitrie O. Paun -
Eric Pouech -
Francois Gouget -
Geoff Thorpe -
Greg Turner -
Johan Gill -
Marcus Meissner -
Matthew Bloch -
Ove Kaaven -
P. Christeas -
Peter Andersson -
Raul Dias -
Shachar Shemesh -
Vincent Béron