Funny enough limiting entry points does not cost that much. Average .so calls on Linux are still less than the windows call to a dll when anti-virus is running. Pax did it on Linux for a long time. Again presuming non exported memory zones have to be marked read write when in application context. So the internal memory structs of .so can be off limits. This is currently not done without real high need. There is no exploit there that the code for the complier and mandatory access control systems cannot activate. It is a simple case of ownership tracking. Simple reason that you are not getting. Linux secuirty could be set like fort knox. Its designed to lock the system down to make any attack as hard as possible minor costs to performance are tolerated. The cost is way less than running an anti-virus on windows. Linux hidden heuristic anti-virus is the mandatory access control system. Yes there are two paths to do heuristics. One is have a stack of signatures and search every program you run against them that comes with about a 20 percent cpu overhead. Or the second remove means to tamper that comes with about a 2 percent cost. Linux has chosen the latter yes locking entry points and internal memory in selected .so files cost nothing compared to running signatures on everything. Normal win32 applications running in wine will never need to reach out to the OS. So mandatory access control profile creators would be perfectly in there rights to forbid this. For the small numbers of applications that do it rules could be customized. So maintaining max strength against intrusion. Informing you uses that you require to do this is required so mandatory access controls can be opened up if required. Large section of wine dlls can be built for windows by the way. So don't interact with Linux syscalls directly so would not need to be protected from tampering. For over 90 percent of all windows applications out there the mandatory access control policy could be set to max on all syscall locations with memory protection and rest of wine forbin from using syscalls. Because the dll you normally would tamper with under windows have no ability to do anything to breach the sandbox. Even if there was a reason why you need to tamper with a protected dll this is still no reason why the syscall could not be moved into a internal and controlled .so that does not exist on windows. In that case application trying to directly access internal .so could be classed as an attack. One of the prototype mandatory access control systems does flow monitoring between .so files. There is no way out. You have to accept this. If there is a way around the mandatory access control system you have found a flaw in the mandatory access control system that needs fixing. If user does not want you going to / they can set it in the secuirty profile on wine. You go around the drive mappings could land in instant application termination even using the mappings you cannot presume you have been granted the rights to run /bin/sh if you have not asked for that right. Linux developers are use to these restrictions. This is why applications have list of parts they depend on under Linux so secuirty can be set right for them. Instant termination when a person is half way through working on something does not make them happy with you. You have just become what you would call an anti-virus false positive that blocked your program from running and terminated it. Basically you are talking about breaking a anti-virus. Should not a anti-virus kick you in the teeth for doing something strange. Linux mandatory access controls have not worries about doing it. If Linux does come under major threat from viruses its mandatory access control systems will have to be turned up. Effectively closing the door on the viruses and any miss behaving applications.
