> I can write some code that simply reads the token from > ~/.launchpadlib/credentials/quickly and attempts to use it to add a new > GPG key if you are in ~ubuntu-core-dev, and so gets a secret key that > can sign packages that can end up on millions of machines. A very > tagetted attack like that would hard to prevent, because there is clearly a > lot of desire. However, as one of the people that could be exploited in > this manner I am wary of anything that makes it possible.
OK, we can make WRITE_SECURITY_SENSITIVE a time-limited token that must be reacquired, say, once an hour. Or we can make it a one-shot token that must be acquired anew every time you want to perform one of these actions. However, such a system destructively interferes with our plan for a desktop credential management app. Let me explain. I'm now working on adding *another* OAuth access level, GRANT_PERMISSIONS. This access level is only officially available to the credential management app. The point of GRANT_PERMISSIONS is to make it possible to create new OAuth tokens without opening the user's web browser. The credential management app will ask the end-user to grant or deny access within a native GUI window rather than within the web browser. You point out that it's easy for a malicious application to get another application's OAuth credentials. This is true whether the credential's access level is WRITE_SECURITY_SENSITIVE or GRANT_PERMISSIONS. (Hiding the GRANT_PERMISSIONS credential somewhere other than the file system won't help: in the worst case, a malicious application can impersonate the Launchpad credential management app over DBus.) If you have GRANT_PERMISSIONS, you can grant yourself any other level of access, including WRITE_SECURITY_SENSITIVE. It's no secret that I think the desktop credential management app, although superior from a UI standpoint, is insecure. Up to this point the counter-argument has prevailed that malicious client code on an Ubuntu desktop is rare, so we shouldn't worry about it. I think this counter-argument has an additional premise that has just been revealed: malicious client code on an Ubuntu desktop is rare, *and if it does exist, the worst it can do is screw up your own system/Launchpad account*. With GRANT_PERMISSIONS plus the ability to upload GPG keys, once malicious code gets on an Ubuntu system it can easily infect thousands of other systems. The obvious solution is to prohibit GRANT_PERMISSIONS from being used to grant WRITE_SECURITY_SENSITIVE. This means that WRITE_SECURITY_SENSITIVE cannot be obtained through the desktop credential management app. Every time you want WRITE_SECURITY_SENSITIVE, you will have to open the user's web browser and tell them: "Quickly wants to do a very dangerous thing with your Launchpad account. Because the thing Quickly wants to do is so dangerous, 1) you need to make doubly certain that you trust Quickly with your Launchpad account, 2) you need to authorize Quickly in your web browser because we can't even trust the Launchpad credential manager in this situation." Since WRITE_SECURITY_SENSITIVE is either a time-limited or a one-shot authorization, the end-user will find themselves authorizing in the web browser every time they want to do something dangerous, plus authorizing in the Launchpad credential app every time they start using a new app, plus using the web browser to authorize the Launchpad credential manager itself. To summarize, a totally new user will need to do the following to upload a GPG key to Launchpad: 1. Authorize the Launchpad credential manager using the web browser. 2. Authorize Quickly for WRITE_PUBLIC using the credential manager. 3. Authorize Quickly for WRITE_SECURITY_SENSITIVE using the web browser. 4. Upload the SSH key. Or, if WRITE_SECURITY_SENSITIVE is time-limited rather than one-shot, you could implement this: 1. Authorize Quickly for WRITE_SECURITY_SENSITIVE using the web browser. 2. Upload the SSH key before the credential expires. (In the second case, once the credential expires, the end-user will completely lose the ability to use Quickly. Next time the end-user wants to use Quickly, they will need to once again authorize Quickly for WRITE_SECURITY_SENSITIVE, or else authorize the Launchpad credential manager and then use the credential manager to authorize Quickly for WRITE_PUBLIC .) Is this acceptable? Is there a better solution? Leonard
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
