I am attempting to get ready to allow for more community support of the packaging methods from Appupdater. However, there are a number of security concerns that I need to address first. Most of these have probably been addressed with Linux package managers, which I need to do some more research on.
1. A "package" XML can run any system command as administrator with full file system access. I don't see any way around this due to the nature of what Appupdater does, this is essential to keep your programs up to date. Can we somehow limit or vet what a "bad" package is so malicious code can't be run on projects with appupdater? Can we quarantine package installation somehow to a certain part of the filesystem?
2. A fully decentralized model can cause problems, namely duplicate package names. I imagine a number of programs may want the package name "pdf" or "vnc" or "office" so there needs to be a way to distinguish or prioritize these or you may install something different than expected.
3. "Bad" binary installers downloaded and installed, perhaps by a package maintainer gone bad or a hacked website. I'm not sure if there is much we can do about this one, maybe just make sure the download hash matches the publically downloadable file. But that doesn't prevent an author from just changing the package file, unless there is some sort of review process.
Possible solutions:
1. Digital signatures. Can we leverage this somehow like the Linux distros do? Maybe each application package should be signed by my "nabber.org" key or some other trusted certifying authority of "goodness" of a package that there are no malicious commands. This is too labor intensive for evaluating downloaded binaries, so this really doesn't help when trusting the installed code itself. This of course would be an option in the program, to require signatures or not, depending on your situation.
Neil
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes I've looked at some of the ways the Linux distros do it and I'm looking for something a little more decentralized. The way these usually work is one key signs all the packages in a single repository, done.
What I'd like to do is have more options and allow for multiple signatures. So for instance, I could sign a package, the program author could sign the package, and even you could the sign the package. That way I could in theory only install packages signed by you because I don't trust anyone else. Or I could install packages signed directly by the author if I import those keys. The cryptographic separation like this is pretty straight forward, the problem I'm wrestling with now is where the signature files actually reside. You shouldn't be required to have me or the author add your signature files to the package or even to our website. And how do we even index packages in this case, can we just do it by name, or should we be covering the URL to the package? What if URL changes? What if package name changes (GAIM -> Pidgin)? Do we need to include signatures in apps.xml? Is that even safe? Or do we need a new list of signature files to go out and grab?
Just thinking out loud, I'll probably have better insight as I think this through more.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok here's my plan for going ahead on this issue, we are already at stage 2:
1. Server Side: Allow others to create repositories and add them to the config file manual, similar to apt's sources.list.
Client Side: Only the "official" repository will be included by default.
2. Client Side: Take bugs and fix them. There may be issues if repositories "overlap."
3. Client Side: Add option to cryptographically sign apps.xml, versions.xml, probably using gpg. There will be a directory of public keys to accept and a config file option on to allow or deny files that fail or are missing a signature. Probably of the form SIG_CHECK = REQUIRE, REQUEST, SKIP. Where REQUIRE won't install anything without a valid signature, REQUEST will install anything with a valid signature or no signature (but not failed signatures), SKIP doesn't check any signatures (current mode).
Server Side: The signature will reside in some pre-defined place, probably in the same directory like apps.sig and versions.sig. Possible XML file additions (see below).
4. Server Side: User community can sign package lists (*.xml) with their GPG key. Post .sig files to internet.
Client Side: Add option to look for user apps.sig and versions.sig URLs, similar to apps.xml files. Will match signatures to *.xml files based on hash of content (URL independent). Possibly add a setting to require X number of valid user signatures before repository is deemed "good."
Other notes on possible apps.xml, versions.xml changes:
- add a tag to describe multiple .sig file locations (both)
- add a tag to suggest other repositories to user (apps.xml)
- add a tag to describe where the public key can be obtained from (automatically, both)
- add time last modified tag (both)
Anyone else have any comments or thoughts on these?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just checked in stage 3! I made the following changes from the above description:
- There is no default location for signature files, it must be defined in the XML file itself.
- There is not a public key directory, instead I added the capability for auto-keying. The server side must support this (just a tag in the XML file).
- Jumped ahead to stage 4 and added some XML tags to define where the signature is.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am attempting to get ready to allow for more community support of the packaging methods from Appupdater. However, there are a number of security concerns that I need to address first. Most of these have probably been addressed with Linux package managers, which I need to do some more research on.
1. A "package" XML can run any system command as administrator with full file system access. I don't see any way around this due to the nature of what Appupdater does, this is essential to keep your programs up to date. Can we somehow limit or vet what a "bad" package is so malicious code can't be run on projects with appupdater? Can we quarantine package installation somehow to a certain part of the filesystem?
2. A fully decentralized model can cause problems, namely duplicate package names. I imagine a number of programs may want the package name "pdf" or "vnc" or "office" so there needs to be a way to distinguish or prioritize these or you may install something different than expected.
3. "Bad" binary installers downloaded and installed, perhaps by a package maintainer gone bad or a hacked website. I'm not sure if there is much we can do about this one, maybe just make sure the download hash matches the publically downloadable file. But that doesn't prevent an author from just changing the package file, unless there is some sort of review process.
Possible solutions:
1. Digital signatures. Can we leverage this somehow like the Linux distros do? Maybe each application package should be signed by my "nabber.org" key or some other trusted certifying authority of "goodness" of a package that there are no malicious commands. This is too labor intensive for evaluating downloaded binaries, so this really doesn't help when trusting the installed code itself. This of course would be an option in the program, to require signatures or not, depending on your situation.
Neil
don't the linux distros sign the package list?
might be worth asking for advice on the yum mailing list: http://linux.duke.edu/projects/yum/
Yes I've looked at some of the ways the Linux distros do it and I'm looking for something a little more decentralized. The way these usually work is one key signs all the packages in a single repository, done.
What I'd like to do is have more options and allow for multiple signatures. So for instance, I could sign a package, the program author could sign the package, and even you could the sign the package. That way I could in theory only install packages signed by you because I don't trust anyone else. Or I could install packages signed directly by the author if I import those keys. The cryptographic separation like this is pretty straight forward, the problem I'm wrestling with now is where the signature files actually reside. You shouldn't be required to have me or the author add your signature files to the package or even to our website. And how do we even index packages in this case, can we just do it by name, or should we be covering the URL to the package? What if URL changes? What if package name changes (GAIM -> Pidgin)? Do we need to include signatures in apps.xml? Is that even safe? Or do we need a new list of signature files to go out and grab?
Just thinking out loud, I'll probably have better insight as I think this through more.
Ok here's my plan for going ahead on this issue, we are already at stage 2:
1. Server Side: Allow others to create repositories and add them to the config file manual, similar to apt's sources.list.
Client Side: Only the "official" repository will be included by default.
2. Client Side: Take bugs and fix them. There may be issues if repositories "overlap."
3. Client Side: Add option to cryptographically sign apps.xml, versions.xml, probably using gpg. There will be a directory of public keys to accept and a config file option on to allow or deny files that fail or are missing a signature. Probably of the form SIG_CHECK = REQUIRE, REQUEST, SKIP. Where REQUIRE won't install anything without a valid signature, REQUEST will install anything with a valid signature or no signature (but not failed signatures), SKIP doesn't check any signatures (current mode).
Server Side: The signature will reside in some pre-defined place, probably in the same directory like apps.sig and versions.sig. Possible XML file additions (see below).
4. Server Side: User community can sign package lists (*.xml) with their GPG key. Post .sig files to internet.
Client Side: Add option to look for user apps.sig and versions.sig URLs, similar to apps.xml files. Will match signatures to *.xml files based on hash of content (URL independent). Possibly add a setting to require X number of valid user signatures before repository is deemed "good."
Other notes on possible apps.xml, versions.xml changes:
- add a tag to describe multiple .sig file locations (both)
- add a tag to suggest other repositories to user (apps.xml)
- add a tag to describe where the public key can be obtained from (automatically, both)
- add time last modified tag (both)
Anyone else have any comments or thoughts on these?
Just checked in stage 3! I made the following changes from the above description:
- There is no default location for signature files, it must be defined in the XML file itself.
- There is not a public key directory, instead I added the capability for auto-keying. The server side must support this (just a tag in the XML file).
- Jumped ahead to stage 4 and added some XML tags to define where the signature is.