@erights mentioned he wanted to discuss Membranes and give practical knowledge of Agoric's deployments of them that are in production today. I think this would be good in light of https://github.com/nodejs/security-wg/pull/352 which might be more robust if Membranes are seen as reasonable after discussing them.
In particular, I am hoping to set aside a meeting time to discuss the experience of them in real world applications and a place to field potential questions. We could do this during a weekly meeting but I feel like having a solid hour on this topic would be ideal as it is a lot of ground to cover and explain.
@nodejs/security-wg please chime in on
1) have during regularly scheduled meeting
2) schedule a separate meeting
In terms of what you would most likely make time for.
I pinged @erights and he thinks it might overflow into 1h:30m more likely since 1h of solid presentation is what he is thinking it would take.
... it might overflow into 1h:30m more likely since 1h of solid presentation is what he is thinking it would take.
This sounds like a separate meeting then. Perhaps what might work is to have it in the same meeting slot as the usual WG meeting, but delayed by a week, and scheduled for 1h30m. In that case, it would be August 16, 19:00-20:30 UTC. (That is, starting at 12:00 in SF, 15:00 NYC, 21:00 Europe.)
I'm away the week of Aug 16, but I doubt we'll be able to find a time that works for everybody. We should try to record though, so people can watch afterwards.
Sorry for the ignorance but what's Membranes? 👶
Maybe the week after then?
I should be ok with the week after, but don't wait for me if Aug 16 works for everybody else.
@lirantal Membranes are a term associated with the Object Capabilities Security Model. Mark is one of the foremost people on this and has worked with JS implementing this approach of security for years at Google, on TC39, etc. as well as having written his own programming language implementing this. I think he could provide valuable insight into the feasibility of adopting a full security model such as Object Capabilities. In the past people have been concerned with performance implications and feasibility, so I want to get him to present to the WG.
Sounds interesting!
Mark says he would like to do it on the 23rd. I'm trying to get him up to speed on how the WG works in general and he might pop in on this issue :).
@nodejs/tsc @addaleax the security working group just scheduled this meeting for Aug 23 3-4:30 EDT, hope to get attendance broader than just the TSC.
[EDITED by @Trott to update time zone from EST to EDT to prevent possible off-by-one-hour errors for anyone doing the time zone math.)
cc @bengl @mikesamuel @deian @jasnell @mcollina @bnb @drifkin @thlorenz @gireeshpunathil who were present at post-Node Summit in person meeting (based on https://github.com/nodejs/security-wg/issues/350 and my memory)
23rd should work for me
I would like to attend too. 23rd works.
I would like to keep this separate from nodejs/node#22112
nodejs/node#22112 is of great value for accidental permissions granting, but this discussion should is intended to discuss a Security Model that is able to handle malicious attacks.
The tradeoffs in such a model are likely to contain breaking changes for user code when enabled, such as freezing globals. Therefore, I feel it is valuable to treat these two different approaches as serving different consumers of Node.js and being able to live harmoniously with each other.
@bmeck You may want to add your last comment, since the issue you’re referring to is this particular issue
(If you are talking about https://github.com/nodejs/node/pull/22112 I disagree, btw.)
@addaleax we can feel free to disagree, but a variety of issues with just disabling features exist as are mentioned on your PR. The PR does not feel like a suitable place to discuss the problems with such an approach to security to me though, so I've just stated in my comment that I'd like to see the reasoning about why to choose that model is a blocker for me.
@lirantal To expand on @bmeck's answer:
Tom Van Cutsem @tvcutsem recently published a great piece on membranes which points to JS specific details.
"Jul 22, 2018 - Isolating application sub-components with membranes"
Membranes are a defensive programming pattern used to intermediate between sub-components of an application. The pattern is applicable in any memory-safe programming language, and I explain elsewhere on this blog how they work in JavaScript.
The pattern has been around for many years, but is not widely known. My aim in this article is to lay out the general ideas behind membranes. Because most of my experience with membranes has been built up in the context of Web standards, I will mostly be covering this from the angle of JavaScript and Web platform-related use cases.
Operating systems commonly employ a variety of protection mechanisms to coordinate the interaction between applications. Processes, for example, introduce distinct address spaces to isolate applications from each other.
Membranes are a secure programming pattern that achieve a similar kind of isolation, but within a single application rather than between different applications. The name “membrane” is meant to evoke an association with cell membranes, which protect delicate internals from a chaotic external environment while still enabling regulated interaction with that environment.
One advantage of using membranes to isolate different parts of an application is that the objects on different sides of the membrane still reside in the same address space, and so can still communicate through standard programming abstractions such as method calls or field accesses. They can also share direct pointers to (usually immutable) shared state. This is very different from isolation through process-like abstractions, which introduce separate address spaces.
Btw, Tom did the bulk of the spec work for JavaScript Proxy.
Thanks @mikesamuel!
Meeting scheduled for Aug 23rd at 3 EST.
@mhdawson I'm on vacation and was wondering if that session will be recorded like normal sessions so I can watch it afterwards?
Meeting scheduled for Aug 23rd at 3 EST.
3 EDT, not EST, for anyone plugging it into an online timezone calculator (which is probably no one, but JUST IN CASE...)
@lirantal will plan to record.
@erights You can add the link to the challenge here :)
For the challenge, see
https://rawgit.com/Agoric/SES/master/demo/?dateNow=enabled
with explanation and source at
Thanks everyone!
@erights do you have an idea of quick we could PoC this into Node.js? This could be a good first step to collect feedback from the Node.js community and the use cases they might have.
Recording is here: https://www.youtube.com/watch?v=lgAnL1swyns
I created a version with corrected visuals at
https://www.youtube.com/watch?v=9Snbss_tawI&t=0s&list=PLKr-mvz8uvUgybLg53lgXSeLOp4BiwvB2&index=23
Is it possible for Node to link to this one instead?
@vdeturckheim should be. Please contact me at erights (at) gmail (dot) (you know the rest).
Sorry it took so long, but per the request about how to implement a security model I took some time to gather data from various parties.
I've come back after some conversations with others per the final request for a plan on how to implement a security model with a draft document for how we could implement the variety of pieces to create a system that works for Node : https://docs.google.com/document/d/1h__FmXsEWRuNrzAV_l3Iw9i_z8fCXSokGfBiW8-nDNg/edit#heading=h.a3fvn8g1h48h
This is a draft with a large ability to change, in particular it seems some thoughts are being floated around about keeping things out of process entirely due to skepticism for things like Spectre, code signing, and isolation. We need to setup various calls and take notes with the relevant parties. I think we can/should make separate issues for each of those as they show up? This would be a large architectural change for Node requiring a process runner instead of single process for applications, and might not be complete for a variety of use cases that Node serves such as integration with C++ modules.
The draft was modeled with the idea of each feature building upon each other in a manner that allows for increased reliability; however, code signing likely can be punted until integrity checks are in place as integrity checks serves the larger use case of when applications are not seeking to revoke trust and is easier to implement.
Chris Palmer has some discussion he would like to have around how to implement a variety of things and concerns. I am setting up a meeting next week with him. Apparently either Tuesday or Thursday from 9AM or 9:30AM for 1 hour. If anyone wants to participate, let me know; otherwise, I will be recording the meeting.
I've started implementing the resource integrity checks and a few privileges but it will take quite some time to complete things. I will be closing this issue and opening an impl/planning status tracking issue instead.
Most helpful comment
For the challenge, see
https://rawgit.com/Agoric/SES/master/demo/?dateNow=enabled
with explanation and source at
https://github.com/Agoric/SES/tree/master/demo