andreaplanet > So everyone who want to detect Wine must create his own exe.so? Ok, but if it is hardened through a sandbox then still can I run it? With a sandbox can I run a native linux binary distributed together with my application? Reason exe.so are loaded by the wine loader. Same as your .exe if sandbox blocks the wine loader exe's of either form will not load so for wine to work it has to allow it. Now wine loader on the other hand can be set to refuse it. You can provide users with instructions to get around that. AppArmor no. Selinux and smack harded yes. Selinux and smack can rule out program from loading other native programs completely with wine. Unless Selinux or smack approves you program to run particular native programs it cannot under hardened this even applies to native programs. Really makes attacking linux servers that are hardened fully pain in ass. Just coping in a elf file and trying to run it on a hardened system just sets off the alarms. To be correct selinux or smack can take ext-ream offense to it and terminate a program for attempting to do something it did not approve. Selinux can also restrict the native .so files your programs can talk to. So if wine does not use a .so file and you decide to reach out and use something wine does not use you can almost bet in a hardened system you just got the application killed. Selinux or smack when it terminates a program will not give program notice that it is doing so. It will just simply clean the program from memory. Its not something you want happening half way threw a write. Linux's hardened are a complete different game to windows. Linux does not take the soft method of answer you were not approved to do that. Simply just kills the program. Yes Linux systems can have a hitman standing over your shoulder waiting to take your application out. exe.so must only be Dependant on win32 dlls provide by wine and the right platform not to risk being blocked by a sandbox. Even probing can get touchy if wine passes a wrong platform elf to system because it don't id as a exe.so selinux and smack can kill application. Sandboxed to hell. There is no way out. This is why I am saying it is better to tell the user and provide a wine tickbox and the like so user ticks wine and you can include like this program will use the following extra native parts please make sure wine/application has secuirty permissions to use them. Anything native person sandboxed many need to turn off. Also the reason why you might have to provide more than 1 workaround methods. Ie one using replacement win32 dlls and one using native parts. Reason why I keep pointing to the installer. The difference dealing with a OS who secuirty system can truly work and has the mind that a harmless program killed by mistake is better than letting a harmful program pass. By the way AppArmor is a complete joke of a mandatory access control system. Its not included in main line kernel because its file access controls can be bypassed. Someone really need to update it to support the secure path based system provided in 2.6.29 and on. Bug numbers sound fine in theory. Until you wake up Wine bugzilla has been compacted 6 times so far. Closed bugs removed and new bugs give there bug numbers. Yes wine recycles bug numbers. One of the open bugs is to try to make wine pull theming from user desktop and make wine look as close as native without breaking application compatibility. Wine really does not want to make applications in wine look like windows. Its just side effect from not being able to join the theming engines up.
