It's mandatory on all sandboxing systems and for good reasons: sandboxing and identity are intimately related. To be usable the OS must cache permissions you grant the app but if your app isn't signed then nothing stops another app impersonating you and using your cached permissions.
This is true for literally every user-facing sandboxing system even when it may seem that it's not the case. For example, the web ties app identity to the domain name from where it was downloaded, but asserted domain name isn't good enough so in practice browsers require SSL/TLS for most permissions (which requires a certificate and is a form of pseudo-"signing").
It's even true on Linux. The designs on Linux aren't as robust or decentralised as on macOS or Windows, but packages are signed there too by your distro provider. Although you can install packages from outside the distro and thus work around this system, by doing so you disable any protections against apps stealing cached resources (exception: I think Flatpak doesn't have this problem but it uses a more store-like model where the store operators are expected to stop apps impersonating each other and if you install other "stores" then all bets are off again).
Now all that said. Conveyor (see my other post in this thread) can produce self-signed MSIXs, and those are fully fledged MSIX packages that will be able to take part in sandboxing when it's finally released. Installing such packages requires admin elevation because the installer has to add your self-signed root certificate to the user's trust store, and that's equivalent to overriding the protections (you could then sign an app as if it came from anyone). But it can be useful in corporate environments where the certificate is pre-distributed via Active Directory.
It's still silly to not allow sandboxing of unsigned binaries. There could at least be a user sandbox where all non-signed apps can live. There could be an option for a temporary sandbox. And so on.
There could be many useful options which would still improve security incrementally.
But with MSIX requiring installation, couldn't the cached credentials be tied to the container? I would think that the OS would need to protect the container to some extent, and thus an application that could break into the container would effectively already have filesystem privileges equivalent to administrator access.
It'd be more tolerable if self-signed certificates were allowed without janky workarounds like adding them to the cert store. There are too many significant downsides to commercial code signing certificates for individuals, like cost, loss of anonymity, certificates getting revoked for bogus reasons like antivirus false positives, and the slow creep toward more things requiring EV (like maintaining reputation). The majority of the time, the only actual trust I have in an application and its developer is from past history, and for that all I need is assurance that a new version was signed by the same entity as the last version.
The container identity is derived from the certificate identity in Windows.
Now, you could say that's wrong and it should be derived from the public key instead. That's how Android does it. It means self-signing works. But, Microsoft want the ability to make malware bans stick, and that means tying apps to something expensive to forge yet cheap to produce one or two of, and which can be used to inflict real world consequences for online actions (malware). Real-world identity does that.
Public keys have another problem: people lose them. Google had to give up on letting developers manage their own keys eventually. The OS still understands that, but most apps are distributed through the Play Store and when you do that Google re-signs your software with server side controlled keys. This ties apps to Google accounts instead of private keys, which is much safer for the developer (in availability terms).
MSIX identity has a similar problem - sometimes companies change their names, and sometimes CAs disagree on how a name should be formatted. Windows has a mechanism to let people migrate between names, but it's badly designed and basically unusable. Conveyor provides its own system that's more robust.
> There are too many significant downsides to commercial code signing certificates for individuals, like cost, loss of anonymity, certificates getting revoked for bogus reasons like antivirus false positives, and the slow creep toward more things requiring EV (like maintaining reputation).
Microsoft will sign your software for you if you ship via the Microsoft Store, and charge you a one-off $19 fee. So that's basically ~free. Conveyor can make MSIX packages and upload them to the store for you, and can do so from Linux or macOS, so cost is no longer an obstacle to being signed (although you do have to meet the Store policies).
Certificates don't get revoked for AV false positives. Apple doesn't care what AV vendors think and on Windows certificates are actually never revoked, not even if used unambiguously to sign malware. They're working on changing that at the moment but it's slow going due to the need for precise policies; it will certainly not be so trigger-happy as to be caused by AV false positives.
You can't be anonymous in any software distribution platform meant for end users. Even on the web, you need to buy a domain name and that means tying your name to a payment system that is required by law to verify your government-issued identity. All apparent anonymity on the web is simply having other people stand in your place and agree to take the bullets on your behalf, which can be done with code signing as well.
The exceptions are platforms meant only for software developers (Homebrew, Docker Hub, NPM etc) which I think don't do any ID verification, but they are also centralized and expected to police the packages they ship by their users. Arguably they don't and this is blowing up in the industries face, usually this is called the supply chain crisis. It's possible that code signing will come for libraries at some point too if we don't figure out in-process sandboxing and make it ubiquitous.
> The majority of the time, the only actual trust I have in an application and its developer is from past history
That's exactly what code signing is for: allowing you to develop a trust in the reputation of a developer. But it has to be ignited by something. If you don't have that then you can never install any newly developed software, which is infeasible and so you probably do install software from developers with unknown reputation.
I think a better argument against the way code signing works is that it should accept a domain name as an identity, like the web does. The code PKI system assumes that trust accumulates into individuals or companies, but on the internet trust mostly accumulates through social networks and links, which go to domain names not companies.
> Public keys have another problem: people lose them. Google had to give up on letting developers manage their own keys eventually. The OS still understands that, but most apps are distributed through the Play Store and when you do that Google re-signs your software with server side controlled keys. This ties apps to Google accounts instead of private keys, which is much safer for the developer (in availability terms).
So, to correct the number of mistakes in that:
- Apps distributed through Google Play are only resigned if the developer has uploaded their key to Google Play, or created the app within the last year
- Google added the resigning not to improve availability, but instead to allow Google Play to modify the included libraries and dependencies in the app ad-hoc
- For apps created within the last year, as the developer does not have access to their signing key, they cannot redistribute the app outside of the play store, which was the main goal from Google
- The vast majority of apps installed today, even when installed through the play store, are still signed by the developer
This is true for literally every user-facing sandboxing system even when it may seem that it's not the case. For example, the web ties app identity to the domain name from where it was downloaded, but asserted domain name isn't good enough so in practice browsers require SSL/TLS for most permissions (which requires a certificate and is a form of pseudo-"signing").
It's even true on Linux. The designs on Linux aren't as robust or decentralised as on macOS or Windows, but packages are signed there too by your distro provider. Although you can install packages from outside the distro and thus work around this system, by doing so you disable any protections against apps stealing cached resources (exception: I think Flatpak doesn't have this problem but it uses a more store-like model where the store operators are expected to stop apps impersonating each other and if you install other "stores" then all bets are off again).
Now all that said. Conveyor (see my other post in this thread) can produce self-signed MSIXs, and those are fully fledged MSIX packages that will be able to take part in sandboxing when it's finally released. Installing such packages requires admin elevation because the installer has to add your self-signed root certificate to the user's trust store, and that's equivalent to overriding the protections (you could then sign an app as if it came from anyone). But it can be useful in corporate environments where the certificate is pre-distributed via Active Directory.