What's the security story for package installation?


#1

If I install a package, does that immediately give it access to my computer as my user? Or are packages sandboxed in some way?

It would be nice if most packages only got access to the text of the document I use them on, and that only when I actually invoke them.


Privacy issues
/deep/ and ::shadow becoming deprecated?
#2

The short answers are “yes” and “no”, respectively.

What would be your suggestion for how to manage exceptions to the “most packages” rule you specify?


#3

You’ll need a permissions system of some sort.

For permission requests on the open web, we’ve been leaning toward a mechanism similar to, but not exactly the same as Notification.requestPermission. The key features would be:

  • The package calls a function to request the permission.
  • This function returns a Promise that accepts or rejects depending on whether the user granted the permission.
  • To give yourself room to evolve in the future, define this sort of function even for permissions that you expect to grant by default. The editor can accept the promise without prompting the user in these cases.
  • Also provide a function to check whether the package has permission, so it can tailor its initial request to be in a context the user expects.

I’m not sure what features node.js provides to isolate different packages. In Chrome, V8 lets us use distinct Contexts to segregate content scripts from the web page they run inside, so we can give them different permissions.


#4

All of your suggestions are great as far as a permissions system goes …

But what would it look like from the perspective of the user? Personally, I like the current system of “If I don’t trust it, I don’t install it”. Are you suggesting the user get prompted on installation of the package? Are you suggesting the user get prompted on activation of the feature in question? What happens if a package is designed to do something “on save”? Won’t a dialog box popping up when someone just wants to save something be really confusing? (And worse yet … what if the user says no? Does the file not get saved?)


#5

I don’t trust any random developer with full access to my computer, so I can’t currently install any packages not written by the atom team or another group that I’ve heard of. I’d like to be able to use Atom packages like I currently browse the web, where I mostly don’t have to worry about avoiding sites written by people I don’t fully trust.

The Android experience has shown pretty clearly that asking on installation isn’t effective in the long run. It’s a good UI for packages that do only one thing, but multi-purpose applications use it to gradually extend the number of things they can do as the user.

I’m suggesting that the user be asked at a time the package developer chooses, but probably at about the time the package first uses the feature.

If a package is designed to do something that needs system access “on save”, it’s likely to show a dialog while the user’s saving a file, shortly after it’s installed. You’d probably want to arrange the “on save” event to be either “before save” or “after save”. Rejecting a permission requested during “after save” wouldn’t have any effect on whether the save happens. Another package might want to provide a network target for saving files. That would need to intercept “before save” and request network access. Rejecting that request would probably proceed to the normal save dialog instead of the package’s custom version.


#6

This means you cannot use any editor or IDE on “the market” today that supports the concept of plugins/packages. I am violently opposed to introducing a permission system, and I’m sure mostly everyone is. The package reporting feature on atom.io is good enough for getting rid of any potentially malicious packages. Besides with the way the package infrastructure is set up, you have full access to the code of any published package, which means you can check it doesn’t do anything naughty (or stupid) prior to installing it.


#7

This means you cannot use any editor or IDE on “the market” today that supports the concept of plugins/packages.

I don’t want to burst anyone’s bubble here, but… javascript programmers aren’t exactly considered the paragons of security. Packages like remote-sync, [remote-edit][2], [atom-terminal][3], [terminal-runner][4], [term2][5] while nifty and useful concepts in a general sense, are pretty egregious security holes waiting to happen.

When you consider the nodejs ecosystem where it’s basically just a free-for-all of who puts what up and forks with similar sounding names lurk behind each corner - it’s not even a matter of the atom.io packages being ‘malicious’, they don’t have to be. They just need one of their 50-60 npm downloaded modules written by a person one step further removed from you to be malicious.

Here’s a great example:

h t tps://www.npmjs.org/package/jQuery maintained by coolaj86, treasonx, rwaldron

and then right next to it

h t tps://www.npmjs.org/package/jquery, maintained by dmethvin, scott.gonzalez, m_gol

And the funny part is, the ‘jQuery’ project looks like the imposter. And that’s only based on
the fact that they link to the project’s real github page. I have no idea if it’s legit. The guy
writing atom.io addons doesn’t know if they’re legit. You need to think big picture.


#8

As Atom becomes more popular this will become a bigger issue. Even just from a stability point of view, we shouldn’t allow installed packages to (easily) affect the stability of the main Atom Editor/UI.

One way to improve the current situation is to map out what permissions are required for a particular package to run (ideally both dynamically and statically).

This would allow an OAuth like workflow where the user is able to make security decisions. For example when I install a package like layout-manager, I wouldn’t expect that package to also have access to my file system and (for example) modify the actual Atom application code.

Of course that at the moment Node and JS makes some of this Sandboxing quite hard, but that is definitely an area that will see a lot of action and development over the next couple years