On Sat, Jun 6, 2009 at 1:13 AM, oiaohm<wineforum-user@xxxxxxxxxx> wrote: > Protected loads of dll.so files can also be limited. You are describing same kinds of exploitation faults these secuirty designers are working against. > > System call protection prototypes also prevents from entering libs through non exposed calls. Ie if the dll.so does not export it there you cannot enter execution there. The branching attack is included. From a wine point of view a .dll.so rendered not patch-able would not be a issue. Wine would work normally. Only programs doing things they should not be doing would be effected. Then if program wants to patch dll solution would be to provide a normal dll without syscall usage. Absolutely. Any particular attack I propose can probably be addressed by an update, and of course I'm picking the obvious ones. The problem is that to secure a system in this way, you theoretically have to think of all of them, and you have to make Wine perfect (in that it cannot be fooled into doing something it wouldn't normally be able to coaxed into doing, since it is apparently trusted more than the program is). By limiting the entry points, you reduce the ways to interact with system dll's, but the possible interactions are still quite complicated and effectively impossible to turn into a real security boundary. I still have the general ability to mess with the internal data structures of the Wine libraries and to give the functions unexpected input, potentially bending them to my evil will. Limiting the entry points must be costly to performance. Each attempt to execute code on the other side of the boundary must cause an exception so that it can be validated by the OS (and presumably some alteration of virtual memory). Patching system dll's in memory is a perfectly normal thing to do on Windows, and if Wine cannot allow this then Wine is broken. Yes, it's bad practice. Yes, it's prone to breakage even under normal (Windows) circumstances if there is an update. But it is not uncommon on Windows and so it must work on Wine. We have a perfectly good security boundary between the process and everything else. Why try to create another one within the process? > By the way Vincent Provirk lot of nocd hacks and game cheats trip straight up over Linux secuirty even when it set on low because they try to edit forbin memory sections. That still makes Wine broken, even if OS limitations make it unfixable. There are many bugs like that. > This is why presuming you have a hole in Linux secuirty is bad. One day it will be taken away from you and your application will snap. It will produce a nice little secuirty report saying what you tried to do. > > You are simply failing to understand you cannot design under Linux and expect to use any form of secuirty hole. Doing so is asking for your application to fail. What I'm failing to understand is why you think the ability to see the host OS from a Windows program running in Wine is anything like a security hole. If Wine itself can do something, there's no security reason that a Windows program shouldn't be able to do it. Yes, trying to use Linux syscalls in a Windows program (as well as branching to non-entry-points, messing with internal structures, giving unexpected input, etc.) is evil and prone to breaking. There's simply no reason to do it when there are better ways. For example, I can use native Wine API's to convert paths and start, say, /bin/sh. But this isn't about security. It's about compatibility (these evil methods make assumptions that may not always be true) and respecting the user (if the user does choose to not map /, going around the drive mappings is simply rude).
