5 ms·

"connect to an existing node" is going to be amazing. I imagine two interesting uses for this. 1. producing reports. Connect a livebook session to your syste

"connect to an existing node" is going to be amazing. I imagine two interesting uses for this. 1. producing reports. Connect a livebook session to your system in prod, run a livebook (which pulls data from DB eg), then get back a report. User engagement, cloud resources consumed, p90s, or an incident report... 2. manual database intervention. Suppose you need to manually make a batch of changes to the DB. It would be very cool if you could run a livebook inside of a sandboxed checkout (a temporary transaction) and write your db changes, then write your code that verifies that the db is in a state that you want it to be in. If you mess up your code, then you just terminate the transaction without committing. Then when you're happy with your notebook, you run it once with a commit at the end, and then save your notebook immutably in your records so that you can keep track of what you've done. I think for intervening in prod, it would be very cool if someone could figure out how to extend erlang distribution over websockets so you don't have to figure out complicated mechanisms (open up ssh port, forward encrypted epmd, e.g.) to get into your system in prod

qbasic_forever 6y ago
Be careful, websockets are tricky to secure and get right. It's easy to do something like forget to check the origin and now you've opened up a whole class of cross-site websocket scripting attacks. I love the idea of easy access and nice UI to prod machines, but put it behind a secure proxy or VPN layer and not facing the public internet.
- dnautics 6y ago
  That's very reasonable.
- bcardarella 6y ago
  Phoenix Channels accounts for many of these attack vectors. Livebook uses Phoenix LiveView which is built on Phoenix Channels.
- wrren 6y ago
  'Connect to an existing node' is likely implemented using ERTS (http://erlang.org/doc/reference_manual/distributed.html http://erlang.org/doc/reference_manual/distributed.html). So you're basically connecting to the runtime of the target node. The security model for ERTS isn't great, though, so your point stands. All you need is a matching secure cookie and you can connect and run any commands you want.
  - qbasic_forever 6y ago
    Yep, and then the temptation to fix it is to roll your own homebrew auth over websockets... which is super risky.
    - dnautics 6y ago
      I imagine that such a solution would be a public package/extension with eyes on it.
  - lostcolony 6y ago
    To put context on that - it's still TLS, the cookie is just a password. The problem is that it's one password for the node network, and you either have it, or you don't. So there's no real administrative control over access; it's shared password.
    - qbasic_forever 6y ago
      And a browser can be tricked into sending the cookie if you accidentally misconfigure the server. You will have no indication or warning of this happening, from either the client or server side, if you get it wrong.
      - lostcolony 6y ago
        >> if you accidentally misconfigure the server Sure, but I mean...
      - gallexme 6y ago
- exikyut 6y ago
  Hmmm. Nginx has an auth_subrequest module that yeets all the cookies in a requests over to a configured URL in a server-initiated subrequest (hence the name), then proceeds with the original request only if the subrequest returns 200 OK. The module works with any type of incoming request, including FastCGI and reverse proxy situations. The idea is that some config magic turns the 401 into a 302 redirect that walks you through a single-signon page, then you get redirected back to wherever you left off. However since you can make failed requests do just about anything you could technically reroute the request to a WebSocket server that just serves error responses or something, but that feels very... wronky. The module does feel somewhat unwieldy to use in general as well, although this may be due to general unfamiliarity on my part with Nginx's way of doing things (which I'd summarize as "AAAAAAaaaaaaaa (aaa!)"). (The whole `if`-statements-can-SEGV thing etc.) The module can only return 200 (allow original request through) or 401 (deny original request); any other response causes nginx to cancel the original request and return 503. (In case of 401, anything else, or error, the FastCGI server or upstream never sees a connection at all.) It's possible to pass interesting state information such as a username or non-opaque session token from the subrequest to the main request by capturing subrequest response headers then injecting them as request headers into the main request, but this is sufficiently into the weeds (and unlike any existing system Web developers would typically have experience with) that I have a strong tendency to just go \ N O \, but considering that it is admittedly an obscure yet established corner of nginx's configuration, I figured I'd say something for completeness... for the benefit of the 2 people still reading up to this point. :D I've incidentally been trying to figure out how to set up a simple BeyondCorp-esque system with it for a while now (for remote access to home systems, so focusing mostly focusing on brain-dead simplicity), but the giant brick wall I keep running into is how to a) make things auth-aware, b) keep the cookie properly opaque, and b) prevent everything from exploding horribly if auth_subrequest gets turned off. The only method I can think of to enable (b) (so that individual services don't have to duplicate auth logic, kind of defeats the point) is to pass headers out from the subrequest, which then breaks (c) (making it possible to access things directly). A small microservice that handles the cookie side of things and makes HTTP requests itself starts looking like a breath of fresh air...
  - rad_gruchalski 6y ago
nonbirithm 6y ago
I wish nREPL would be standardized to be non-Clojure-specific as with LSP, so you could connect to a program written in any language with an nREPL server and poke at it. This is basically the Elixir version of that.
devoutsalsa 6y ago
We use Elixir at work. I attach to a running sapp all the time. It’s great!

qbasic_forever 6y ago

Be careful, websockets are tricky to secure and get right. It's easy to do something like forget to check the origin and now you've opened up a whole class of cross-site websocket scripting attacks. I love the idea of easy access and nice UI to prod machines, but put it behind a secure proxy or VPN layer and not facing the public internet.

dnautics 6y ago
That's very reasonable.
bcardarella 6y ago
Phoenix Channels accounts for many of these attack vectors. Livebook uses Phoenix LiveView which is built on Phoenix Channels.
wrren 6y ago
'Connect to an existing node' is likely implemented using ERTS (http://erlang.org/doc/reference_manual/distributed.html http://erlang.org/doc/reference_manual/distributed.html). So you're basically connecting to the runtime of the target node. The security model for ERTS isn't great, though, so your point stands. All you need is a matching secure cookie and you can connect and run any commands you want.
- qbasic_forever 6y ago
  Yep, and then the temptation to fix it is to roll your own homebrew auth over websockets... which is super risky.
  - dnautics 6y ago
    I imagine that such a solution would be a public package/extension with eyes on it.
- lostcolony 6y ago
  To put context on that - it's still TLS, the cookie is just a password. The problem is that it's one password for the node network, and you either have it, or you don't. So there's no real administrative control over access; it's shared password.
  - qbasic_forever 6y ago
    And a browser can be tricked into sending the cookie if you accidentally misconfigure the server. You will have no indication or warning of this happening, from either the client or server side, if you get it wrong.
    - lostcolony 6y ago
      >> if you accidentally misconfigure the server Sure, but I mean...
    - gallexme 6y ago
exikyut 6y ago
Hmmm. Nginx has an auth_subrequest module that yeets all the cookies in a requests over to a configured URL in a server-initiated subrequest (hence the name), then proceeds with the original request only if the subrequest returns 200 OK. The module works with any type of incoming request, including FastCGI and reverse proxy situations. The idea is that some config magic turns the 401 into a 302 redirect that walks you through a single-signon page, then you get redirected back to wherever you left off. However since you can make failed requests do just about anything you could technically reroute the request to a WebSocket server that just serves error responses or something, but that feels very... wronky. The module does feel somewhat unwieldy to use in general as well, although this may be due to general unfamiliarity on my part with Nginx's way of doing things (which I'd summarize as "AAAAAAaaaaaaaa (aaa!)"). (The whole `if`-statements-can-SEGV thing etc.) The module can only return 200 (allow original request through) or 401 (deny original request); any other response causes nginx to cancel the original request and return 503. (In case of 401, anything else, or error, the FastCGI server or upstream never sees a connection at all.) It's possible to pass interesting state information such as a username or non-opaque session token from the subrequest to the main request by capturing subrequest response headers then injecting them as request headers into the main request, but this is sufficiently into the weeds (and unlike any existing system Web developers would typically have experience with) that I have a strong tendency to just go \ N O \, but considering that it is admittedly an obscure yet established corner of nginx's configuration, I figured I'd say something for completeness... for the benefit of the 2 people still reading up to this point. :D I've incidentally been trying to figure out how to set up a simple BeyondCorp-esque system with it for a while now (for remote access to home systems, so focusing mostly focusing on brain-dead simplicity), but the giant brick wall I keep running into is how to a) make things auth-aware, b) keep the cookie properly opaque, and b) prevent everything from exploding horribly if auth_subrequest gets turned off. The only method I can think of to enable (b) (so that individual services don't have to duplicate auth logic, kind of defeats the point) is to pass headers out from the subrequest, which then breaks (c) (making it possible to access things directly). A small microservice that handles the cookie side of things and makes HTTP requests itself starts looking like a breath of fresh air...
- rad_gruchalski 6y ago

nonbirithm 6y ago

I wish nREPL would be standardized to be non-Clojure-specific as with LSP, so you could connect to a program written in any language with an nREPL server and poke at it. This is basically the Elixir version of that.

devoutsalsa 6y ago

We use Elixir at work. I attach to a running sapp all the time. It’s great!