Show HN: Osgood – A secure, fast, and simple JavaScript server platform | Hacker News Reader

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

github.com

106 pointstlhunter22 comments

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)

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.

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/#...

Having the ability to whitelist particular URLs (or at least domains) is really really cool. This would prevent (or make much harder) many of previous npm packages hacks.

Maybe you guys should work together with deno team on exchanging these ideas? Anyway, great work!

> Today these policies are all-or-nothing

No, Deno supports whitelists for net and file access:

https://deno.land/manual.html#permissionswhitelist

Super good explanation, and congrats this project. Would be helpful to your cause if you put this right in the README.md

> 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?"

Isn’t this also the PHP, Allaire ColdFusion, and ASP/ASP.net experiment, each making a very different set of tradeoffs? Or successors such as OpenRESTY with built in LuaJIT?

It’s true a lot of “we” think web apps are built in general purpose runtimes, but plenty who think that’s lower ROI, so there’s a body of prior art here.

Excited to see experiments continuing this direction. Also consider looking back over past 25 years to when that question was first experimented with — which concepts stuck the landing, which concepts were left behind, and why.

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.

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.

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?

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

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?

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?

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.

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

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?

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

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).

Are you from Fremont?

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?

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.

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.

Reply on news.ycombinator.com