search

Meteor-Community-Packages / stratosphere

Meteor private package server
MIT License
28 stars 7 forks source link

What should security look like? #7

Open hellogerard opened 9 years ago

hellogerard commented 9 years ago

Awesome to see RC1!

I think security is the next big priority. What would that look like? I can think of a couple issues:

  1. Secure the front-end.

    At the very least, just put everything behind a normal Meteor login screen. Login via Meteor Developer account. I read this in the Meteor docs:

    More functionality for OAuth clients. Currently, OAuth clients can check that the user is authenticated as a Meteor developer and get their username, but that's all they can do. Apps can't receive your email address or check your organization membership. We could give apps the ability to prompt users for permission to do these things.

    So it does not seem you could restrict logins by Meteor org, for example. There used to be an allowedUsers settings. I think hard-coding names in this way is perfectly fine. Can we use that to restrict logins to the front-end?

  2. Secure meteor-tool.

    I'm not familiar with the innards of meteor-tool. What commands does it authenticate for? Is it in any way possible to restrict any command that interacts with Stratosphere? That is, a user should have to authenticate to run meteor add/remove, meteor search/show against Stratosphere.

Just putting some thoughts down...

sebakerckhof commented 9 years ago

It would only require a change of 2 lines of code to Stratosphere to secure the frontend and syncing of packages. In fact, at first I had done this, but had to disable this because of the way meteor-tool works.

meteor-tool only tries to authenticate before commands that add or change data like meteor publish or meteor publish-release .

Therefore, I cannot secure the synchronization of packages (because meteor-tool does not try to login for this).

The only thing you could do is add your own release track with your own version of meteor-tool. I'd welcome a PR request for this, but I'm not going to write this myself since I just run stratosphere inside a firewall protected area of my company and don't want to maintain my own meteor track.

sebakerckhof commented 9 years ago

Btw, the publishing of data can already be secured. by enabling loginRequired and setting a superUser in the settings.json file.

hellogerard commented 9 years ago

It would only require a change of 2 lines of code to Stratosphere to secure the frontend and syncing of packages.

If I understand, the front-end is already close to getting a login screen? That is, it would be easy to simply preventing anyone in the world from navigating to your Stratosphere install URL, and viewing packages, regardless of meteor-tool.

As for meteor-tool, I understand the issue. What I am thinking now would be an npm CLI program (maybe called ozone :smile:) that talks to Stratosphere. It would have handle its own authentication, but delegate to meteor-tool when the time is right. Stratosphere would also need to prevent direct access from meteor-tool via the environment variable.

Sounds like lots of work, for sure. Thoughts?

sebakerckhof commented 9 years ago

If I understand, the front-end is already close to getting a login screen? ...

Exact

What I am thinking now would be an npm CLI program

I think it'd be much easier to run your own version of meteor-tool. All that would be required is an authenticated connection for all package related commands (as is already done for publishing). The problem is that you'd have to maintain this tool and create your own release track and so on, which I don't want / can't commit to.