4 ms·

I wonder how it would be, had capability-based system architectures taken off and become mainstream. I guess we wouldn't need WebAssembly to run untrusted code

I wonder how it would be, had capability-based system architectures taken off and become mainstream. I guess we wouldn't need WebAssembly to run untrusted code safely, because in such a system, all objects – from whole programs to an object as small as the number 4 – would be safe and sealed off from each other on a hardware level. I'm reading Capability-Based Computer Systems [0] by Henry M. Levy (1984), motivated by wanting to learn about the Burroughs B5000 that Alan Kay has praised multiple times. I've only started to learn about these things and I don't understand the implications, but if I'm reading it correctly, such architectures would obviate the need for web-style safety measures such as process-sandboxing ala Chrome, shader sanitizing ala WebGL, etc, because everything in the system would be safe that way. [0] https://books.google.de/books/about/Capability_Based_Computer_Systems.html?id=eT6eBQAAQBAJ&redir_esc=y&hl=en https://books.google.de/books/about/Capability_Based_Compute... More about this: https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security and https://en.wikipedia.org/wiki/Capability-based_addressing https://en.wikipedia.org/wiki/Capability-based_addressing

akavel 9y ago
You may like browsing through comments by @nickpsecurity (e.g. https://news.ycombinator.com/threads?id=nickpsecurity&next=14474149 https://news.ycombinator.com/threads?id=nickpsecurity&next=1..., etc.). He's really knowledgeable about this stuff, and tries to popularize it as much as he can.
- thingification 9y ago
  On display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”, is this mailing list: https://groups.google.com/forum/#!forum/cap-talk https://groups.google.com/forum/#!forum/cap-talk
  - AriaMinaei 9y ago
    There is a trove of very interesting information here. Thanks akavel and thingification :)
  - akavel 9y ago
    Ah; more off-topic than not, but this reminded me of another fairly obscure, yet super interesting mailing list — The Risks Digest, on air since 1985: https://catless.ncl.ac.uk/Risks/ https://catless.ncl.ac.uk/Risks/
Someone 9y ago
In case you don't have it yet: "the Burroughs B5000 conference" (http://conservancy.umn.edu/bitstream/handle/11299/107105/oh098b5c.pdf http://conservancy.umn.edu/bitstream/handle/11299/107105/oh0...) is a transcript of a set of discussions held in 1985 by people involved in creating the B5000. I found it an interesting read. Abstract: "The Burroughs 5000 computer series is discussed by individuals responsible for its development and marketing from 1957 through the 1960s in a conference sponsored by AFIPS and Burroughs Corporation. In the first session the technical aspects of the B 5000 and 5500 are discussed by a group of managers, engineers, and consultants. Topics include: the state of the industry in the late 1950s; the 5000's predecessors, particularly the ElectroData 101 and 201, B 205, and B 220; factors influencing the decision to produce the B 5000; reasons for designing the machine for ALGOL rather than FORTRAN and the effect of this decision on the computer's development and sales. The group reviews the MCP operating system, PERM, Polish notation, descriptors, stacks, the BALGOL compiler, and other innovations of the computer. In the second session, the same group discusses the development of the B 5000 into a product, including the effect of the administrative organization on the project; the relations between hardware and software engineers; the interaction of project personnel and upper-level management, field marketing, and customers; the COBOL processor, the head protract disk system; the operating system; ALGOL; and documentation of the computer. In the third session managers, sales personnel, and customers of the B 5000 discuss Burroughs' product line before the 200 and 5000 series computers; sales training and market reaction to the B 5000; acceptance of B 5000s at Ohio Oil Company and Stanford University; its rejection by the University of Michigan; reasons why the B 5000 was not marketed overseas; and Burroughs' presidents Raymond Eppert and Ray MacDonald."
flukus 9y ago
Have capability based systems solved the "user clicks yes to everything" problem? Until then they solve nothing.
- thingification 9y ago
  Ha To be honest: Yes? I would say that is the conventional wisdom in the (small) capability community. I'm sure that oversimplifies carefully-nuanced opinions of course, but, yes. An example is mentioned here ('angels', 'Power Boxes'): https://www.cl.cam.ac.uk/research/security/capsicum/ https://www.cl.cam.ac.uk/research/security/capsicum/ The idea is that capability-based user interfaces do not need to ask those "Yes, get my work done/No, be secure" questions in the first place. That idea will be better tested if they ever take off in more than the isolated areas they're currently found of course. Capability security has low adoption in part because of the usual catch-22 (adoption breeds adoption), in part because it's a tricky challenge to retrofit, and in part I think because of a failure to communicate the ideas to the best and most influential implementers - exactly why I don't know.
  - flukus 9y ago
    > and in part I think because of a failure to communicate the ideas to the best and most influential implementers - exactly why I don't know. I agree here, that page is the perfect example, all I see is a page full of academic buzzwords and not a "How this works in practice". So we limit what resources an app has access to, that's easy enough to understand, but what happens when an app needs resource x? Does it have to prompt the user or does it have to have to be granted the access at install time? As far as I'm aware those are the only two options. > The idea is that capability-based user interfaces do not need to ask those "Yes, get my work done/No, be secure" questions in the first place. That idea will be better tested if they ever take off in more than the isolated areas they're currently found of course. It sounds like it has to prompt users to get permissions: > This includes a KDE-based PowerBox scheme allowing sandboxed applications to request user-driven file open using standard dialogs.
    - thingification 9y ago
thingification 9y ago
'Sandboxing' within single processes would still be necessary, at least (and I suspect at many other levels too, practically). I think it is necessary now, but that is not (yet?) appreciated. If you haven't seen it already, I and many better educated people recommend http://www.erights.org/talks/thesis/ http://www.erights.org/talks/thesis/ (a pleasant read, even if I don't judge it by comparison with other theses) - focuses on distributed computation and language-level capabilities

akavel 9y ago

You may like browsing through comments by @nickpsecurity (e.g. https://news.ycombinator.com/threads?id=nickpsecurity&next=14474149 https://news.ycombinator.com/threads?id=nickpsecurity&next=1..., etc.). He's really knowledgeable about this stuff, and tries to popularize it as much as he can.

thingification 9y ago
On display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”, is this mailing list: https://groups.google.com/forum/#!forum/cap-talk https://groups.google.com/forum/#!forum/cap-talk
- AriaMinaei 9y ago
  There is a trove of very interesting information here. Thanks akavel and thingification :)
- akavel 9y ago
  Ah; more off-topic than not, but this reminded me of another fairly obscure, yet super interesting mailing list — The Risks Digest, on air since 1985: https://catless.ncl.ac.uk/Risks/ https://catless.ncl.ac.uk/Risks/

Someone 9y ago

In case you don't have it yet: "the Burroughs B5000 conference" (http://conservancy.umn.edu/bitstream/handle/11299/107105/oh098b5c.pdf http://conservancy.umn.edu/bitstream/handle/11299/107105/oh0...) is a transcript of a set of discussions held in 1985 by people involved in creating the B5000. I found it an interesting read. Abstract: "The Burroughs 5000 computer series is discussed by individuals responsible for its development and marketing from 1957 through the 1960s in a conference sponsored by AFIPS and Burroughs Corporation. In the first session the technical aspects of the B 5000 and 5500 are discussed by a group of managers, engineers, and consultants. Topics include: the state of the industry in the late 1950s; the 5000's predecessors, particularly the ElectroData 101 and 201, B 205, and B 220; factors influencing the decision to produce the B 5000; reasons for designing the machine for ALGOL rather than FORTRAN and the effect of this decision on the computer's development and sales. The group reviews the MCP operating system, PERM, Polish notation, descriptors, stacks, the BALGOL compiler, and other innovations of the computer. In the second session, the same group discusses the development of the B 5000 into a product, including the effect of the administrative organization on the project; the relations between hardware and software engineers; the interaction of project personnel and upper-level management, field marketing, and customers; the COBOL processor, the head protract disk system; the operating system; ALGOL; and documentation of the computer. In the third session managers, sales personnel, and customers of the B 5000 discuss Burroughs' product line before the 200 and 5000 series computers; sales training and market reaction to the B 5000; acceptance of B 5000s at Ohio Oil Company and Stanford University; its rejection by the University of Michigan; reasons why the B 5000 was not marketed overseas; and Burroughs' presidents Raymond Eppert and Ray MacDonald."

flukus 9y ago

Have capability based systems solved the "user clicks yes to everything" problem? Until then they solve nothing.

thingification 9y ago
Ha To be honest: Yes? I would say that is the conventional wisdom in the (small) capability community. I'm sure that oversimplifies carefully-nuanced opinions of course, but, yes. An example is mentioned here ('angels', 'Power Boxes'): https://www.cl.cam.ac.uk/research/security/capsicum/ https://www.cl.cam.ac.uk/research/security/capsicum/ The idea is that capability-based user interfaces do not need to ask those "Yes, get my work done/No, be secure" questions in the first place. That idea will be better tested if they ever take off in more than the isolated areas they're currently found of course. Capability security has low adoption in part because of the usual catch-22 (adoption breeds adoption), in part because it's a tricky challenge to retrofit, and in part I think because of a failure to communicate the ideas to the best and most influential implementers - exactly why I don't know.
- flukus 9y ago
  > and in part I think because of a failure to communicate the ideas to the best and most influential implementers - exactly why I don't know. I agree here, that page is the perfect example, all I see is a page full of academic buzzwords and not a "How this works in practice". So we limit what resources an app has access to, that's easy enough to understand, but what happens when an app needs resource x? Does it have to prompt the user or does it have to have to be granted the access at install time? As far as I'm aware those are the only two options. > The idea is that capability-based user interfaces do not need to ask those "Yes, get my work done/No, be secure" questions in the first place. That idea will be better tested if they ever take off in more than the isolated areas they're currently found of course. It sounds like it has to prompt users to get permissions: > This includes a KDE-based PowerBox scheme allowing sandboxed applications to request user-driven file open using standard dialogs.
  - thingification 9y ago

thingification 9y ago

'Sandboxing' within single processes would still be necessary, at least (and I suspect at many other levels too, practically). I think it is necessary now, but that is not (yet?) appreciated. If you haven't seen it already, I and many better educated people recommend http://www.erights.org/talks/thesis/ http://www.erights.org/talks/thesis/ (a pleasant read, even if I don't judge it by comparison with other theses) - focuses on distributed computation and language-level capabilities