On Sat, Jun 6, 2009 at 9:27 AM, oiaohm<wineforum-user@xxxxxxxxxx> wrote: > 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. There will always be something else. If you want real security, you need a GENERAL PRINCIPLE that can be applied two all points of interaction between two things. > 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. Sure, the individual cases can be fixed, but this is an approach of starting with an assumption that's fundamentally flawed (Wine libraries and the running application can be treated differently) and fixing individual cases. Things will always be missed. There is always a way out. It's not a sound approach. There is an opposite approach that you can take: Isolate each running application (and, in cases where it makes sense, further divisions within an application, enforced by actually having separate processes) from each other and from data that belongs to the user. You can then enumerate the points of interaction and secure them. Essentially, you start with something secure (but also useless), and allow things as needed, in a sound way, until it is useful. This approach can provide real security. The other one can't. > 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. No, but on a normal system I can assume that if I don't have the rights to /bin/sh, the attempt will just fail. If a user CONFIGURES HIS SYSTEM to instantly terminate apps when they do something he doesn't expect, I don't see how he could be unhappy when it happens. Surely he should be happy that his security system has protected him from the document he was working on. > 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. If Linux does come under major threat from viruses, you'll also likely see a corresponding change in Windows software. Developers will start targeting Wine as an actual platform (in fact, a few do it already). And they will take advantage of the fact that Wine runs on a Unix-like system. Inevitably even apps that don't will trip mines. The end result is that such a minefield security system will make Wine appear broken to the user. People don't want to dig into software configurations when things don't work. They want things to just work. Users will only see that the system does not work and use something else.
