6 ms·

> e.g. constantly having to allow applications access to files outside the initial default sandbox. Any system that has ordinary users trying to do this for or

by zrm 7y ago

> e.g. constantly having to allow applications access to files outside the initial default sandbox. Any system that has ordinary users trying to do this for ordinary software will fail. Things like apparmor can work well because the author or distributor of a package knows that it shouldn't ever do a particular thing, so if it attempts to, that is a bug and it should be refused. The user shouldn't even have to be aware that this is the case because the program shouldn't even attempt to do the thing the author/distributor asserted it will never do. > It also seems clear that this concept ultimately heads towards signing application binaries, like macOS. Linux has had that for years already. Packages are signed by the distributor. Nobody complains about it there because the device owner can authorize additional parties to sign packages for their machine, as it should be. Have a look at the install instructions for Signal Desktop for Debian on signal.org -- "sudo apt-key add" etc. You can also install binaries outside the package manager, and then the filesystem executable bit serves a similar purpose -- disabled by default but the user can override it.

PaulDavisThe1st 7y ago
I'm the original/lead author of a large cross-platform application that runs on Linux, macOS and Windows. Trust me when I say that there is no such thing as application signing on Linux. We don't care what Linux distributions do - we would prefer if they didn't package our application, because 99% of them are incapable of doing it right. We can't stop them, because GPL. The situation on Catalina is completely different, and cannot be compared with the executable bit.
- 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).
danieldk 7y ago
Things like apparmor can work well because the author or distributor of a package knows that it shouldn't ever do a particular thing, so if it attempts to, that is a bug and it should be refused. The user shouldn't even have to be aware that this is the case because the program shouldn't even attempt to do the thing the author/distributor asserted it will never do. The AppArmor + vendor-provided profiles doesn't work, because it means that you have to give most applications access to the user's full home directory. If you e.g. have an office suite and don't permit full home directory access, users will bail out because they cannot open files in their random folder structure. If you permit full home access, it could be exploited to exfiltrate data, write malicious files, etc. macOS solves this by using a privileged service for Open/Save dialog boxes. If you ask for an open dialog in a sandboxed application, it is handled by this privileged service, which makes the file available in the application's sandbox. It is quite elegant, because it does not require the user to follow any additional steps (it works as any other file dialog), but restricts an application to its own sandbox. Flatpak also follows this approach with its portal mechanism (which is unfortunately not supported by every application yet).
- zrm 7y ago
  > The AppArmor + vendor-provided profiles doesn't work, because it means that you have to give most applications access to the user's full home directory. It works fine. Its purpose is to solve a different problem than this. > macOS solves this by using a privileged service for Open/Save dialog boxes. There are circumstances where this can be useful, and it would be fine to implement this on Linux for applications where it's appropriate, but it doesn't work as a universal rule. For example, suppose I have a music player app, I choose open, I get the dialog and choose a playlist. The playlist file is just a list of paths to music files which were never selected in the dialog. The app still needs to open all the music files. And the same thing for office documents with links to images, source code project files etc. And what about background services? If I install an app to make regular backups of my home directory then it needs access to the whole thing, and not just once. Likewise anything that does indexing, malware scanning etc. So it's still really the same thing. You have an app that asserts it never needs access to files outside the open dialog and then it can be restricted to just that, but other apps need to do different things. You need somebody to identify which apps can do without certain capabilities, the average user is not equipped for that, so it falls to the author or the packager.

by zrm 7y ago

PaulDavisThe1st 7y ago

I'm the original/lead author of a large cross-platform application that runs on Linux, macOS and Windows. Trust me when I say that there is no such thing as application signing on Linux. We don't care what Linux distributions do - we would prefer if they didn't package our application, because 99% of them are incapable of doing it right. We can't stop them, because GPL. The situation on Catalina is completely different, and cannot be compared with the executable bit.

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).

danieldk 7y ago

Things like apparmor can work well because the author or distributor of a package knows that it shouldn't ever do a particular thing, so if it attempts to, that is a bug and it should be refused. The user shouldn't even have to be aware that this is the case because the program shouldn't even attempt to do the thing the author/distributor asserted it will never do. The AppArmor + vendor-provided profiles doesn't work, because it means that you have to give most applications access to the user's full home directory. If you e.g. have an office suite and don't permit full home directory access, users will bail out because they cannot open files in their random folder structure. If you permit full home access, it could be exploited to exfiltrate data, write malicious files, etc. macOS solves this by using a privileged service for Open/Save dialog boxes. If you ask for an open dialog in a sandboxed application, it is handled by this privileged service, which makes the file available in the application's sandbox. It is quite elegant, because it does not require the user to follow any additional steps (it works as any other file dialog), but restricts an application to its own sandbox. Flatpak also follows this approach with its portal mechanism (which is unfortunately not supported by every application yet).

zrm 7y ago
> The AppArmor + vendor-provided profiles doesn't work, because it means that you have to give most applications access to the user's full home directory. It works fine. Its purpose is to solve a different problem than this. > macOS solves this by using a privileged service for Open/Save dialog boxes. There are circumstances where this can be useful, and it would be fine to implement this on Linux for applications where it's appropriate, but it doesn't work as a universal rule. For example, suppose I have a music player app, I choose open, I get the dialog and choose a playlist. The playlist file is just a list of paths to music files which were never selected in the dialog. The app still needs to open all the music files. And the same thing for office documents with links to images, source code project files etc. And what about background services? If I install an app to make regular backups of my home directory then it needs access to the whole thing, and not just once. Likewise anything that does indexing, malware scanning etc. So it's still really the same thing. You have an app that asserts it never needs access to files outside the open dialog and then it can be restricted to just that, but other apps need to do different things. You need somebody to identify which apps can do without certain capabilities, the average user is not equipped for that, so it falls to the author or the packager.