4 ms·

Packages have signatures on Linux. They're validated during install rather than execution, but validating them on execution wouldn't cause meaningful problems a

by zrm 7y ago

Packages have signatures on Linux. They're validated during install rather than execution, but validating them on execution wouldn't cause meaningful problems as long as the device owner can install additional signing keys. Not being able to do so is what causes your consternation with Catalina. Whether the applications are well-packaged is a different matter, and that's the place where apparmor does get into trouble as well. In theory the packager describes things the application should never do, but if they're sloppy then it actually requires some privileges they didn't grant it, and then you have users mashing every available button to turn off all the security because their application isn't working. This is the constant battle in security. You have false positives and false negatives. You can't err on the side of false positives or people will stop using your system because it constantly gets in their way. You can do a lot of hard work to reduce both false positives and false negatives, but that's a lot of hard work. Or you can err on the side of false negatives, which is nice and easy and doesn't interfere with people using the system, except that it's insecure and then systems eventually get compromised. This turns out to be the one that people tend to prefer in practice. Oops.

danieldk 7y ago
Packages have signatures on Linux. They're validated during install rather than execution, but validating them on execution wouldn't cause meaningful problems as long as the device owner can install additional signing keys. How does an average computer user know how to verify a public key (does it belong to who it claims to belong to)? They won't. I know many long-time Linux users, and they will just copy and paste all installation commands, including apt-key add commands. If a server is compromised, they will just copy and paste an attacker's PGP key. There are many criticism I can make of a centralized certificate authority, such as Apple, but by default Apple's code signing provides far more security for third-party applications. It is far less likely that Apple's key is compromised than the key of some random 3rd party APT repository maintainer. Furthermore, if a Developer's key is compromised, Apple can easily revoke it. A centralized authority has its problems (the authority becomes the gatekeeper). But for most users, it much more secure. So, how do you suggest how to verify a public key for a third-party repository at scale? Most users will not be part of the PGP web of trust and we cannot all meet the author in real life to compare PGP key fingerprints.
- zrm 7y ago
  > So, how do you suggest how to verify a public key for a third-party repository at scale? We already have infrastructure for this. Here's that first line for the Signal installer: > curl -s https://updates.signal.org/desktop/apt/keys.asc | sudo apt-key add - You're getting the key from signal.org over TLS. It's an authenticated channel, the TLS certificate is subject to revocation if compromised. Key distribution isn't the problem. You also don't inherently need a central authority for revocation. There is already a line in sources.list where you're checking for package updates, it would be straightforward to have the package manager to check in the same location for key revocations, or specify another URL to check for that when the key is installed.
  - PaulDavisThe1st 7y ago
    That verifies that the download is as it should be. Apple's app signing verifies that the app is approved by them. Substantively different things (though related).
    - zrm 7y ago
      A package signed with the Debian signing keys proves it is approved by them. A package signed with the Signal Foundation signing keys proves it is approved by them. It's substantively the same thing, you're just enabled to trust multiple independent parties, or yourself if you install something outside of the package manager.
      - danieldk 7y ago
        The point is that downloading a key from a website does not prove that the key belongs to that organization. If the server is compromised, the attacker could replace the public key and TLS would not barf at it. Your reactions perfectly underline my point: most users do not understand trust or if they understand trust at some level, they do not know how to verify trust.
        7y ago
PaulDavisThe1st 7y ago
We are an OEM/ISV, effectively. Even though our software is GPL'ed, we distribute binaries of it for a name-your-own price. There is no signing system when a user installs our builds. Contrast with Catalina, which will not run our application by default (and makes it actually quite tricky for naive users to run at all). I am fully aware of how linux distro packaging works, but that's not the only way applications are distributed, even on linux.

by zrm 7y ago

danieldk 7y ago

Packages have signatures on Linux. They're validated during install rather than execution, but validating them on execution wouldn't cause meaningful problems as long as the device owner can install additional signing keys. How does an average computer user know how to verify a public key (does it belong to who it claims to belong to)? They won't. I know many long-time Linux users, and they will just copy and paste all installation commands, including apt-key add commands. If a server is compromised, they will just copy and paste an attacker's PGP key. There are many criticism I can make of a centralized certificate authority, such as Apple, but by default Apple's code signing provides far more security for third-party applications. It is far less likely that Apple's key is compromised than the key of some random 3rd party APT repository maintainer. Furthermore, if a Developer's key is compromised, Apple can easily revoke it. A centralized authority has its problems (the authority becomes the gatekeeper). But for most users, it much more secure. So, how do you suggest how to verify a public key for a third-party repository at scale? Most users will not be part of the PGP web of trust and we cannot all meet the author in real life to compare PGP key fingerprints.

zrm 7y ago
> So, how do you suggest how to verify a public key for a third-party repository at scale? We already have infrastructure for this. Here's that first line for the Signal installer: > curl -s https://updates.signal.org/desktop/apt/keys.asc | sudo apt-key add - You're getting the key from signal.org over TLS. It's an authenticated channel, the TLS certificate is subject to revocation if compromised. Key distribution isn't the problem. You also don't inherently need a central authority for revocation. There is already a line in sources.list where you're checking for package updates, it would be straightforward to have the package manager to check in the same location for key revocations, or specify another URL to check for that when the key is installed.
- PaulDavisThe1st 7y ago
  That verifies that the download is as it should be. Apple's app signing verifies that the app is approved by them. Substantively different things (though related).
  - zrm 7y ago
    A package signed with the Debian signing keys proves it is approved by them. A package signed with the Signal Foundation signing keys proves it is approved by them. It's substantively the same thing, you're just enabled to trust multiple independent parties, or yourself if you install something outside of the package manager.
    - danieldk 7y ago
      The point is that downloading a key from a website does not prove that the key belongs to that organization. If the server is compromised, the attacker could replace the public key and TLS would not barf at it. Your reactions perfectly underline my point: most users do not understand trust or if they understand trust at some level, they do not know how to verify trust.
      - 7y ago

PaulDavisThe1st 7y ago

We are an OEM/ISV, effectively. Even though our software is GPL'ed, we distribute binaries of it for a name-your-own price. There is no signing system when a user installs our builds. Contrast with Catalina, which will not run our application by default (and makes it actually quite tricky for naive users to run at all). I am fully aware of how linux distro packaging works, but that's not the only way applications are distributed, even on linux.