[1] https://march-lang.org/docs/capabilities/#the-problem-they-s...
This is genuinely useful in a language, but I suspect it’s also pretty weak. Serious capability systems have capabilities that are instances of types, and two instances are not necessarily the same. For example, the capability to read one file is not the capability to read another file. Singletons may still exist: the capability to read the system clock could reasonably be a singleton. (Or not: one may reasonably debate whether the cycle counter and the realtime clock are instances of the same type or not, and you’ll find that mainstream languages have what amount to very different answers to this sort of question.)
The Cap system is modeled on Eiffel and a series of papers I can link to later when I’m at my laptop.
It can audit dependencies for capability changes and can inspect binaries for undeclared IO. The run tool can analyze binaries and refuse to run a binary that tries to hide effects.
March’s capability system can be used to build binaries into a Linux sandbox so that you have multiple layers guarding prohibited actions.
It’s heavily inspired by Eiffel and Pony. It is also coincidentally a lot like Bluefin for Haskell[1], and in that spirit I use them beyond security. For example behavioral promises like no_alloc and no_panic.
I’ve shown to some compiler researchers who understood it to be a capability system. In your mind what makes it not a capability system?
[1] https://h2.jaguarpaw.co.uk/posts/bluefin-capability-system/
My current thinking is to freeze all caps on startup. pid-0 within the runtime has the max caps the application will ever have and it can parcel out subsets to other processes that need it.
This can show up on the ux side as a single permission request listing all the caps the application claims it needs with a default negative response.
Or the language it’s written in allows writing a function that takes a recursive enumerate capability on a directory plus a write capability to stdout.
A while back I sent a brain dump email to LKML about “path capabilities”. Maybe I’ll try to implement it.
Thanks for the thoughtful question!
A couple of thoughts:
- would really like to have the option to make things more granular… things like “which dns/tls will this have access to?”, “which file/folder?” - probably would be helpful to have permissions to be kinda two sided, like “this function needs tls”, and then on the import side “allow this function tls access to this host in particular”.
[1] https://march-lang.org/docs/capabilities/#choosing-the-right...
I liked the security model because at least they had something, unlike node.
A service I use recently introduced mandatory two-step verification. This is good. However, they implemented this by adding the email factor to all accounts. I had much more secure methods configured, but now you can bypass them with email. This is bad. I'm still not sure they understand what a critical security issue this is.
> It does not provide security guarantees in the presence of malicious code. Malicious code can bypass the permission model and execute arbitrary code without the restrictions imposed by the permission model.
The permission model is more of a "help developers not accidentally "rm -rf /" their local machine than it is something that helps end users.
It’s for executing untrusted code written by others… a large subset of Javascript which guarantees the code can only call the Facades you inject, and you can hook and intercept anything. It works with callbacks and promises.
What’s more is that it runs in WebWorker sandboxes on the web, and uses a proxy to transparently make existing code make same method calls, or use existing objects, like window.document, but to safer versions, which only allow eg createElement.
And because SafeScript automatically awaits every async function, your synchronous calls to HTMLElement methods etc. will be proxied asynchronously and “just work” without changing the original JS code. SafeScript is robust enough that most existing JS components will simply work without changes when ported to SafeScript.
PS: It can also be embedded in PHP, so you can run untrusted handlers there, too, without worrying about PHP’s large security surface.
PPS: SafeScript is deterministic by default, so you can also get the same results across all environments or runs. You can set the random number generator seed yourself, or inject Date.now() as one of your APIs if you want.
Here it is. Should I do a Show HN?
Deno should disallow arbitrary output on stdout/stderr. Even prefixing the lines won't work because control characters like ^H are sent in-band and can delete the prefix.
The "in-band vs. out-of-band" is nothing new. Worth looking up 2600hz, the signaling frequency of the US phone system way back when. Pick up a handset, generate a 2600hz tone. Suddenly you're talking to the call routing system. Only a few steps from there to free phone calling anywhere in the world. Call routing signaling should've been separate, out of band - but given the tech at the time they'd have needed extra wires for signal lines ($$$) so the tradeoff was made, risk accepted.
The phone system designers went for in-band signaling to save money. Deno doesn't need to save money by running less copper so my money's on naïveté. Which doesn't bode well.
And the rest of the points made.. well yep the author is on point - made worse by Deno developers publicly defending their wrong choices.
Thankfully there're great alternatives.
My plan was to encode to Unicode (lossily), strip out control characters, and add some visual framing. Anything else I should be considering? Is there a standard approach? Haven't actually done the research on this yet, but since it came up here, I figure someone might know.
(This is https://codeberg.org/timmc/breakmancer if anyone is interested.)
I may have misstated the problem above. What I really need to ensure is that a malicious output can't say "the digest is abc123" and trick the user into pasting that into the other program (when the real digest is def456).
Hmm...
Isn't there a public key based way to avoid needing the user to do this.
Terminals can be configured to render emoji in text presentation form where they become monochrome glyphs that can be colored like ordinary text with escape sequences. Not something to hinge your security model on.
I was a fan of Deno from the beginning, but not targeting NodeJS compatibility at the beginning turned out to be the wrong move. Now Bun gets to be Anthropic's testbed for the future of software development. (Which includes the wholesale plagiarism and optimization of Oxc into its codebase, wowza.)
Side note: `deno fmt` is a great Markdown formatter. I might get around to extracting out just that part of it.
It is self-centered and narcissistic. Why? WTFRU. An opinion isn't an argument. You have to have reasons beyond your opinions and those are what matter. Lead with those, and your opinion is implied by the fact you are talking about it.
Deno's Security Model is a False Sense of Security
Deno's Permissions Are Not a Sandbox
The Illusion of Deno's "Secure by Default" Model
Why --allow-run and Permission Prompts Don't Make Deno Safe
The title weakens an otherwise pretty good article.