> there's frequent interaction between code written by the end developer and code from the library
Microkernel operating systems that use capability security like KeyKOS or one of its distant successors, sel4 focus on optimizing the call procedure as best as they can. A small performance overhead for guaranteed security properties shouldn't be seen as a tradeoff.
>send it to a separate execution environment, and then marshal it right back[...]
Current runtimes of all kinds always need new instances of something to sandbox things, which incurs a big overhead everytime. But it doesn't have to be this way. The KeyKOS kernel was of fixed size, I built my https://esolangs.org/wiki/RarVM to be so, too, it is stateless. No need for several instances of the interpreter itself, and minimal overhead in the process snapshots.
>policy decision about whether to grant privileges [...] people would choose not to use it
The advantage of capability systems (that start with all rights given in every call by default) is that even if people do not initially use it, they can restrict rights later - "hollow out the attack surface", when this makes economical sense - when a library becomes popular, laws or contracts require it etc.
While users may not interact with it directly or choose not to use it, such systems grant developers at least the ability to secure their software internally, something that is not even possible now.
> [...] it's just a safety measure [...] purely-computational libraries can still be dangerous
But this argument doesn't attack the central point. Yes, this is true, but has nothing to do with the security properties offered by POLA architectures like capability security. It's an orthogonal problem, which has to be mitigated by other mechanisms, possibly social.
I think we're disagreeing on what the central point is, then. I think least-privilege architectures are great, and I use them for many things. I think they do not save you from the problem being addressed in this article. That is, do not read what I'm saying as an argument against least-privilege architectures: read it as an argument against using that hammer to drive in this screw.
In turn, I think that means that there isn't enough justification for using them in this case that users will feel like the additional complexity of wiring through least-privilege across their libraries is worth it. Even if you take the approach of incrementally adding the security to the existing design, the implication is it won't actually be securing end users for a long time, and only against minor and unlikely threats at first, but it will impose increasing complexity all along.
KeyKOS is great and I've read about it and tried to adopt its lessons in my own designs, but the fact remains that KeyKOS is dead. And I certainly agree that a small performance overhead for guaranteed security properties shouldn't be seen as a tradeoff (assuming it is in fact solely a performance overhead, and not a developer mental burden, nor a reviewer mental burden, nor an operational burden) - but I'm not commenting on what I see, I'm commenting that the vast majority of NPM users will see it as a tradeoff, regardless of what you and I believe.
Microkernel operating systems that use capability security like KeyKOS or one of its distant successors, sel4 focus on optimizing the call procedure as best as they can. A small performance overhead for guaranteed security properties shouldn't be seen as a tradeoff.
>send it to a separate execution environment, and then marshal it right back[...]
Current runtimes of all kinds always need new instances of something to sandbox things, which incurs a big overhead everytime. But it doesn't have to be this way. The KeyKOS kernel was of fixed size, I built my https://esolangs.org/wiki/RarVM to be so, too, it is stateless. No need for several instances of the interpreter itself, and minimal overhead in the process snapshots.
>policy decision about whether to grant privileges [...] people would choose not to use it
The advantage of capability systems (that start with all rights given in every call by default) is that even if people do not initially use it, they can restrict rights later - "hollow out the attack surface", when this makes economical sense - when a library becomes popular, laws or contracts require it etc.
While users may not interact with it directly or choose not to use it, such systems grant developers at least the ability to secure their software internally, something that is not even possible now.
> [...] it's just a safety measure [...] purely-computational libraries can still be dangerous
But this argument doesn't attack the central point. Yes, this is true, but has nothing to do with the security properties offered by POLA architectures like capability security. It's an orthogonal problem, which has to be mitigated by other mechanisms, possibly social.