{"action":"created","issue":{"url":"https://api.github.com/repos/atom/atom/issues/1763","labels_url":"https://api.github.com/repos/atom/atom/issues/1763/labels{/name}","comments_url":"https://api.github.com/repos/atom/atom/issues/1763/comments","events_url":"https://api.github.com/repos/atom/atom/issues/1763/events","html_url":"https://github.com/atom/atom/issues/1763","id":29603475,"number":1763,"title":"Atom needs a better security model","user":{"login":"nathansobo","id":1789,"avatar_url":"https://avatars.githubusercontent.com/u/1789?v=3","gravatar_id":"","url":"https://api.github.com/users/nathansobo","html_url":"https://github.com/nathansobo","followers_url":"https://api.github.com/users/nathansobo/followers","following_url":"https://api.github.com/users/nathansobo/following{/other_user}","gists_url":"https://api.github.com/users/nathansobo/gists{/gist_id}","starred_url":"https://api.github.com/users/nathansobo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nathansobo/subscriptions","organizations_url":"https://api.github.com/users/nathansobo/orgs","repos_url":"https://api.github.com/users/nathansobo/repos","events_url":"https://api.github.com/users/nathansobo/events{/privacy}","received_events_url":"https://api.github.com/users/nathansobo/received_events","type":"User","site_admin":true},"labels":[{"url":"https://api.github.com/repos/atom/atom/labels/enhancement","name":"enhancement","color":"bfd4f2"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":27,"created_at":"2014-03-17T22:05:38Z","updated_at":"2015-02-05T23:33:30Z","closed_at":null,"body":"If we're going to add GitHub integration to Atom, we need to cache credentials inside the app. We had previously implemented GitHub auth for our Gists package, but we removed both the package and GitHub authentication from the beta release because we were afraid of providing GitHub credentials to every random Atom package people installed. We can't avoid this forever, though. To realize Atom's full potential, we need to solve the security issue in a robust way.\r\n\r\n### What would the ideal security model look like?\r\n\r\n* Every package is loaded in its own context.\r\n* Every package's metadata includes a whitelist of the following:\r\n  * Security-critical properties of the `atom` global requested by the package.\r\n  * Security-critical built-in modules (such as `fs`) requested by the package.\r\n  * Whether the package is allowed to load custom native modules.\r\n  * GitHub permissions the package needs access to and any other credentials.\r\n* When installing a package, the requested permissions are clearly presented.\r\n* If a package attempts to reference or require a resource that isn't white-listed, the user will be explicitly prompted to grant the package that permission.\r\n\r\n### How can we implement this?\r\n\r\nThere's a fairly mature project called [Google Caja][caja], whose goal is to allow multiple mutually-suspicious JavaScript modules to run on the same page securely. To support older versions of JavaScript, they employed a complex whole-program transformation to achieve this. But ES5 incorporates several standard features that allow a context to be secured by running a small JavaScript library called [SES][ses] (short for Secure ECMAScript).\r\n\r\nMy understanding is still evolving, but it seems like we should be able to run the SES script in a fresh context to tamper-proof any globals that we inject into it and secure them from malicious modification or any other kind of privilege escalation. To do this, we'd basically need to provide our own alternative module loading mechanism, which I  started experimenting with this weekend with a fork of Node's built-in `module.js`.\r\n\r\n### What if we miss something?\r\n\r\nSecurity is tough because you only have to screw up once to get exploited. We probably will make a few mistakes. But based on my reading about ES5 and the Caja project, security should be possible in theory. If we implement a security model that leaks, we can fix the problems as we discover them. But if we don't even try then things will never be secure. I think it's worth trying, then subjecting our best effort to an internal and possible external audit.\r\n\r\n### What haven't I thought of?\r\n\r\nThis is all new territory for me. Let me know what I'm missing.\r\n\r\n/cc @github/security @zcbenz @ptoomey3 \r\n\r\n[caja]: https://developers.google.com/caja/\r\n[ses]: https://code.google.com/p/es-lab/wiki/SecureEcmaScript\r\n"},"comment":{"url":"https://api.github.com/repos/atom/atom/issues/comments/73153169","html_url":"https://github.com/atom/atom/issues/1763#issuecomment-73153169","issue_url":"https://api.github.com/repos/atom/atom/issues/1763","id":73153169,"user":{"login":"zephraph","id":3087225,"avatar_url":"https://avatars.githubusercontent.com/u/3087225?v=3","gravatar_id":"","url":"https://api.github.com/users/zephraph","html_url":"https://github.com/zephraph","followers_url":"https://api.github.com/users/zephraph/followers","following_url":"https://api.github.com/users/zephraph/following{/other_user}","gists_url":"https://api.github.com/users/zephraph/gists{/gist_id}","starred_url":"https://api.github.com/users/zephraph/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zephraph/subscriptions","organizations_url":"https://api.github.com/users/zephraph/orgs","repos_url":"https://api.github.com/users/zephraph/repos","events_url":"https://api.github.com/users/zephraph/events{/privacy}","received_events_url":"https://api.github.com/users/zephraph/received_events","type":"User","site_admin":false},"created_at":"2015-02-05T23:33:30Z","updated_at":"2015-02-05T23:33:30Z","body":"I'm starting to feel like this is really just a moot point. \r\n\r\nI've decided I'm going to write a github-auth package for the stuff I'm working on and use keytar to store the tokens. In big bright letters I'll write **ANY PACKAGE CAN ACCESS YOUR TOKENS!**... Yeah. It kinda sucks, but I guess it's not that bad. It's made me definitely stop and think before downloading any packages.\r\n\r\nHey guys, do you think we could have a \"trusted developer\" status or something? I'm not sure how one would go about getting the status, but I think it would help a lot of people. I.E. If someone on the Atom team wrote a package, it's probably safe to use. "}}