Re: How can I detect WINE from my program?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Gimp for Windows]     [Red Hat]     [Samba]     [Yosemite Camping]     [Graphics Cards]     [Wine Home]

  Powered by Linux