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. It is secuirty evolution. Major reason for security personal going after protecting .so is to reduce down the area exploitable. The alteration makes a major difference. If a executable gets flawed and a .so file is using a higher function in a restricted way attackers options are now limited. Compared to executable gets flawed since access to syscall was provided to the application attacker can use syscall any way they see fit. People have already thought up attacks like yours Vincent Provirk and used them against native Linux systems. So secuirty is evolution happens over time to render it useless. This is how Linux and other OS's like it react to secuirty problems. Any application running in wine could find themselves completely walled in. Not by wine but by the OS around it. 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. You are making a very big presume you are allowed to alter .dll.so in the first place even in memory. You don't have to be granted that right. The complete thing can be marked no executable and read only in the executable sections until call to .dll is performed. This does reduce buffer overflow flaws getting into executable memory by the way. Yep entry points can be 100 percent restricted. Editing is out. .dll.so not on a approved list by system secuirty also would not run syscalls either. 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. The point here is if user knows what you want todo. They can open up the security system so you can. It is the application developers fault for the failure because they are trying to treat Linux like windows. Ie can just hack around anything. Linux will not take that method all the time. If your application need to reach outside wine you simply need to be truthful.
