6 ms·

Show HN: Osgood – A secure, fast, and simple JavaScript server platform

106 points by tlhunter 7y ago

MuffinFlavored 7y ago
I see the `benchmarks` folder, but why not run the benchmarks so an end user can quickly compare on known hardware what the differences between node.js are performance wise roughly?
herohamp 7y ago
I really dont see the importance of this security layer, unless you major mess up and start eval'ing user input. I first I thought this was like deno where you provide permissions from the commandline, but providing permissions inside of the code itself really doesnt make much sense to me. Am I missing something/viewing it in the wrong mindset?
- deleted 7y ago
  [deleted]
- bengl 7y ago
  Hi there! I'm one of Osgood's authors. To clarify a few things: 1. Any tool that reduces the privileges of your application code, such as Osgood or Deno, is doing so because application code cannot necessarily be trusted, since you're pulling in external dependencies that can have vulnerabilities or malicious code, and even one's own code may have unknown vulnerabilities that may cause unexpected IO behaviour to happen. 2. The policies you can set with Osgood are defined in a JavaScript file that is run separately from your application code (i.e. the worker files), and it only runs once to build up the policy data structures in native code. This V8 Isolate is then discarded. This means that application code cannot modify its own policies.
- sneak 7y ago
  Most javascript apps are indeed eval’ing user input: they just happen to be users of npm instead of users of the app being run. Same problem, though.
tlhunter 7y ago
OP here. Today we build web applications with general purpose language runtimes. Osgood is an experiment that asks the question: "What if we built a runtime specifically for web apps? What kind of benefits can we get from being at a higher level of abstraction?" Since the Osgood runtime has intimate knowledge of the routing table we get the ability to isolate controllers for free (we refer to these as Workers). The I/O performed by the application, as well as policy enforcement, happens in Rust-land. Each worker has its own set of permissions. Consider the situation where Controller A has permission to send a message to evil.ru, and Controller B has access to user credentials. Within a properly configured Osgood application this means it's not possible to transmit user credentials to evil.ru. (Incidentally our main product transparently provides similar isolation for Node.js apps. The architecture ends up looking quite different because Node.js wasn't created with this concept in mind)
- eatonphil 7y ago
  Looked around your readme and wiki but didn't see anything about this vs. deno? Both are Rust wrappers around V8 with privilege mechanisms. Am I missing anything? Edit: well one difference is that this isn't TypeScript. This is only the subset that is JavaScript.
  - tlhunter 7y ago
    Good question! Deno has four policies that I know of: --allow-write --allow-net --allow-env --allow-run Today these policies are all-or-nothing and they are global to the entire Deno process. Consider and application which _only_ needs to make a GET request to a single GitHub API endpoint. This application will then use the `--allow-net` flag and will be able to communicate with arbitrary sites like evil.ru. However, with Osgood, the permissions are much more granular. One can specify a policy to only get access to _exactly_ what is needed. The permissions are also granular enough to only apply to a subset of the overall application: app.route('GET', '/gh/:username', 'gh.js', policy => { policy.outboundHttp.allowGet('https://api.github.com/users/*/gists'); }); We will add further policies where it makes sense, such as with filesystem access. However, Osgood doesn't aim to be a _general_ platform for running code, so we will likely expose filesystem access in a manner akin to this: https://thomashunter.name/presentations/introducing-osgood/#/39 https://thomashunter.name/presentations/introducing-osgood/#...
JamyDev 7y ago
I definitely like this system of applying policies. Would like to see more than http though, like being able to set policies on execution time (e.g.: avoiding a RegEx DoS), filesystem access (e.g.: logger middleware can only write to /var/log/app), module access (e.g.: code that handles sensitive info like passwords can only load trusted modules), etc Is this the future goal for the project or is it more of a PoC?
- bengl 7y ago
  While we've started with outbound fetch/HTTP, we certainly plan on adding additional functionality over time.
Octoth0rpe 7y ago
This looks nice! One thing that would make this even more interesting to me is to see how close you could make the interface for each route handler to amazon lambda/api gateway. I would love to be able develop something locally using osgood, and then deploy to either hosted osgood or aws lambda/api gateway with minimal fuss, potentially even with a single config file that maps routes/permissions.
gitgud 7y ago
Does this have a package management system? In my opinion, npm is the main benefit of node servers (although it's also the main weakness as far as security is concerned). If there's no package management capability, then do people have to manage dependencies themselves? Or if there is one, how is it more secure/trust-worthy than npm?
- tlhunter 7y ago
  While there currently is no package management system it is possible to use webpack and manually compile certain simpler npm packages (think Lodash) into a format which can be imported by Osgood. We would like to come up with an automated solution for this one day. Since Osgood requires I/O to be whitelisted this removes multiple categories of attacks which would affect Node.js apps loading a malicious module.
mhd 7y ago
I think the most secure thing a JS platform could do is provide a decent vetted standard library, so that one doesn't have to bring in too many potentially insecure random developer github projects in the first place.
kevsim 7y ago
Really like the policy part of this as I’ve been bitten by sloppy Node modules (self inflicted and third party) in the past. However, as this is a JS server runtime and Node is the reigning champ, it would be great to get a section in the README early on about Node compatibility. How much is it going to hurt to move my Node services over?
manav 7y ago
Are you from Fremont?
craftoman 7y ago
What's the differences between a platform and a framework?
- deleted 7y ago
  [deleted]
- tlhunter 7y ago
  I like to think a Platform is something that stands on its own (Browser, Node.js, Xbox One) and a Framework is something which brings code patterns and functionality to an existing platform (jQuery, Express.js, Microsoft XNA).
pavloko 7y ago
This looks promising. Great job! It would be great if Deno and Osgood joined forces and something remarkable came out of it.

106 points by tlhunter 7y ago

I see the `benchmarks` folder, but why not run the benchmarks so an end user can quickly compare on known hardware what the differences between node.js are performance wise roughly?

herohamp 7y ago

I really dont see the importance of this security layer, unless you major mess up and start eval'ing user input. I first I thought this was like deno where you provide permissions from the commandline, but providing permissions inside of the code itself really doesnt make much sense to me. Am I missing something/viewing it in the wrong mindset?

deleted 7y ago
[deleted]
bengl 7y ago
Hi there! I'm one of Osgood's authors. To clarify a few things: 1. Any tool that reduces the privileges of your application code, such as Osgood or Deno, is doing so because application code cannot necessarily be trusted, since you're pulling in external dependencies that can have vulnerabilities or malicious code, and even one's own code may have unknown vulnerabilities that may cause unexpected IO behaviour to happen. 2. The policies you can set with Osgood are defined in a JavaScript file that is run separately from your application code (i.e. the worker files), and it only runs once to build up the policy data structures in native code. This V8 Isolate is then discarded. This means that application code cannot modify its own policies.
sneak 7y ago
Most javascript apps are indeed eval’ing user input: they just happen to be users of npm instead of users of the app being run. Same problem, though.

tlhunter 7y ago

OP here. Today we build web applications with general purpose language runtimes. Osgood is an experiment that asks the question: "What if we built a runtime specifically for web apps? What kind of benefits can we get from being at a higher level of abstraction?" Since the Osgood runtime has intimate knowledge of the routing table we get the ability to isolate controllers for free (we refer to these as Workers). The I/O performed by the application, as well as policy enforcement, happens in Rust-land. Each worker has its own set of permissions. Consider the situation where Controller A has permission to send a message to evil.ru, and Controller B has access to user credentials. Within a properly configured Osgood application this means it's not possible to transmit user credentials to evil.ru. (Incidentally our main product transparently provides similar isolation for Node.js apps. The architecture ends up looking quite different because Node.js wasn't created with this concept in mind)

eatonphil 7y ago
Looked around your readme and wiki but didn't see anything about this vs. deno? Both are Rust wrappers around V8 with privilege mechanisms. Am I missing anything? Edit: well one difference is that this isn't TypeScript. This is only the subset that is JavaScript.
- tlhunter 7y ago
  Good question! Deno has four policies that I know of: --allow-write --allow-net --allow-env --allow-run Today these policies are all-or-nothing and they are global to the entire Deno process. Consider and application which _only_ needs to make a GET request to a single GitHub API endpoint. This application will then use the `--allow-net` flag and will be able to communicate with arbitrary sites like evil.ru. However, with Osgood, the permissions are much more granular. One can specify a policy to only get access to _exactly_ what is needed. The permissions are also granular enough to only apply to a subset of the overall application: app.route('GET', '/gh/:username', 'gh.js', policy => { policy.outboundHttp.allowGet('https://api.github.com/users/*/gists'); }); We will add further policies where it makes sense, such as with filesystem access. However, Osgood doesn't aim to be a _general_ platform for running code, so we will likely expose filesystem access in a manner akin to this: https://thomashunter.name/presentations/introducing-osgood/#/39 https://thomashunter.name/presentations/introducing-osgood/#...

JamyDev 7y ago

I definitely like this system of applying policies. Would like to see more than http though, like being able to set policies on execution time (e.g.: avoiding a RegEx DoS), filesystem access (e.g.: logger middleware can only write to /var/log/app), module access (e.g.: code that handles sensitive info like passwords can only load trusted modules), etc Is this the future goal for the project or is it more of a PoC?

bengl 7y ago
While we've started with outbound fetch/HTTP, we certainly plan on adding additional functionality over time.

Octoth0rpe 7y ago

This looks nice! One thing that would make this even more interesting to me is to see how close you could make the interface for each route handler to amazon lambda/api gateway. I would love to be able develop something locally using osgood, and then deploy to either hosted osgood or aws lambda/api gateway with minimal fuss, potentially even with a single config file that maps routes/permissions.

gitgud 7y ago

Does this have a package management system? In my opinion, npm is the main benefit of node servers (although it's also the main weakness as far as security is concerned). If there's no package management capability, then do people have to manage dependencies themselves? Or if there is one, how is it more secure/trust-worthy than npm?

tlhunter 7y ago
While there currently is no package management system it is possible to use webpack and manually compile certain simpler npm packages (think Lodash) into a format which can be imported by Osgood. We would like to come up with an automated solution for this one day. Since Osgood requires I/O to be whitelisted this removes multiple categories of attacks which would affect Node.js apps loading a malicious module.

mhd 7y ago

I think the most secure thing a JS platform could do is provide a decent vetted standard library, so that one doesn't have to bring in too many potentially insecure random developer github projects in the first place.

kevsim 7y ago

Really like the policy part of this as I’ve been bitten by sloppy Node modules (self inflicted and third party) in the past. However, as this is a JS server runtime and Node is the reigning champ, it would be great to get a section in the README early on about Node compatibility. How much is it going to hurt to move my Node services over?

manav 7y ago

Are you from Fremont?

craftoman 7y ago

What's the differences between a platform and a framework?

deleted 7y ago
[deleted]
tlhunter 7y ago
I like to think a Platform is something that stands on its own (Browser, Node.js, Xbox One) and a Framework is something which brings code patterns and functionality to an existing platform (jQuery, Express.js, Microsoft XNA).

pavloko 7y ago

This looks promising. Great job! It would be great if Deno and Osgood joined forces and something remarkable came out of it.