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