Signature checking in Wine

[Juan Lang]

> Security often involves providing many barriers.  There's a tacit assumption
> that none are going to be perfect.  A common mantra is "security in depth".

Sure.  It's just my professional opinion that a signature on an
application provides no security.  Zip, nada.  It does give you some
assurance of who it came from, that's all.

> As an aside: this looks to me like a logical fallacy.  If I may rephrase your
> argument:
>  1. Most signed software is from a large code-base (probably true)
>  2. Large code-bases are more likely to have vulnerabilities (probably true)
>  3. Therefore, signed software is more likely to have vulnerabilities (wrong:
> not deducible)

That isn't my argument.  My argument is that signatures provide no
guarantees that the code behaves as intended.
1. Software may either contain deliberately malicious code (improbable
but not impossible) or vulnerabilities (generally true)
2. Signed software contains no malicious code (probably true)
3. Signed software can't behave maliciously (wrong).

This isn't true because signed software may contain vulnerabilities,
and these, when exploited, will cause the application to behave
maliciously whether or not the code was signed.  My statements about
the size of signed applications was to emphasize that they may contain
vulnerabilities.

> Well, maybe, but (without being too paranoid) it is possible to target attacks
> against individuals through on-the-fly rewriting of packages, or through DNS
> poisoning, or transparent web-proxies that parse the HTTP User-Agent string,
> or ...

This doesn't pass the likelihood metric of risk analysis.  As you
said, you prioritize in terms of probability x impact.  If probability
is vanishingly small--which I argue it is--it doesn't matter what the
impact is.  If you argue that isn't as small as I claim it is, well,
we can disagree, but now on to the impact:  the impact is you've
installed a piece of software into Wine that claims to be from someone
other than who it's really from.  So what?  What additional rights and
privileges does it gain?  In Wine, none--it always has precisely the
same rights that you do, barring a Wine-specific privilege escalation
attack, which I'll argue is exceedingly unlikely indeed.

That's just the thing--the privilege models in Unix and Windows are
different.  In Windows, just about everybody runs as an administrator
anyway, so at least Microsoft tries to counteract that by providing
signatures on code so users will be more careful about installing
something.  I don't think it's really a security property they're
assuring.  Instead, I think it gives the users a second chance to
decide whether they want to run that cool lemming app someone emailed
them.  In Windows, the risks of running it are very high.  In Linux,
the risks are somewhat lower.

Signatures of automatic software updates are probably useful, but
that's not what we're taling about here.  I continue to maintain that
signatures of random apps people are trying to run in Wine are not.
To be clear, there are three applications I've worked on that use
signature checking:
1. iTunes
2. AIM
3. The DirectX9 runtime

The first two are not trustworthy, no matter what the signatures say,
but people want to run them anyway.  Wine's raison d'etre is to let
people run those applications if they wish.  The DirectX9 runtime only
provides a few usable DLLs that Wine doesn't provide, and that's in
order to get some game to run (I'm guessing, I didn't need it myself.)
 The games are also not trustworthy *cough* rootkit *cough*.

> But, to be honest, I'm a little surprised this made it into wine.  The policy
> used to be something like "no hacks to support a specific application".  I
> haven't seen the patch(es) but from how you've described it, this doesn't
> seem to pass the sniff test.

This isn't a hack.  The code is more correct now than it was, and it
gets a previously running application to run again.  It's just not as
correct as it could be.

Look, I'm not against fixing it at all.  I'm just trying to clear
about what the code does and doesn't do right now.  I have a limited
time to work on this sort of thing, and I feel that keeping
applications from working in the interest of some misguided notion of
security is not in anyone's best interest.

As usual, patches are welcome.
--Juan