Follow

It strikes me that there's a duality of sorts in any kind of remote application:

* the app stays on someone else's computer, you send your data to it: PRIVACY RISK

* the app comes to your computer, you run it there: SECURITY RISK

I think #2 is the best option, because once you send data anywhere you have lost all privacy forever, while you can restrict what foreign code does

but to get there, we need to have languages which are *really* secure against arbitrary untrusted foreign code.

· · Web · 3 · 5 · 10

and no, throwing up our hands and saying "but but the halting problem means we can't do any security checks whatsoever!" is not an answer.

The Halting Problem only applies if you're doing unrestricted self-modifying code with GOTOs everywhere. Are you doing that? Then you shouldn't.

If the Halting Problem applies to your code, *you have written code that you yourself have no way of knowing what it does*.

You should not actually write code that you yourself have no way of knowing what it does.

I mean, unless you're writing the top-level EVAL function of a bare-metal language interpreter which is also an operating system and also its own firmware. In THAT case, I'll let you have 'the user could type in any code and execute it and that is actually the desired system function' as an excuse to invoke the Halting Problem.

But probably not so much otherwise.

If you even have interrupts or RAM limits in your computer, the Halting Problem no longer applies.

@cjd It's what we've got right now, yes, and if civilization crashed tomorrow, Javascript is indeed what we would rebuild civilization upon.

Sleep well with that thought running through your head.

@natecull that's the kind of thing you build a userland dsl with security checks with :p

@natecull
I don't think anybody's seriously throwing up their hands saying this is an unsolvable problem.

Maybe some academic navel-gazer has said this, but if anyone says it in industry they'll be laughed out of the room. JS, WASM, Solidity, SECCOMP, OCaps, etc.

In industry, this is moving slowly because the evolutionary pressure has not become high enough. But cyber-warfare is definitely upping the ante.

@cjd

"I don't think anybody's seriously throwing up their hands saying this is an unsolvable problem."

Well, probably not anyone who matters.

But I've heard this sentiment from programmers on social media MANY times over the last ten years. "Lol you can't just NOT release dangerously insecure software! It's impossible to be secure! Just patch it afterwards!"

I think this is programmer folklore rather than serious computer science. But we have a lot of programmer folklore in this industry.

@natecull
I believe it was Taleb who popularized the notion that a belief is not Good or Bad because of it's factual truth or falsehood but rather in how well it keeps the believer alive.
Programmers need to know just enough to feel ok developing to the requirements the industry has today.

@natecull
And to the second sentence of that comment, I will attach a content warning:

Comments belittling the beliefs/intelligence of 3rd parties play on the mind's desire for superiority, making it harder to objectively validate said comments.

@natecull Enforcing CPU/RAM limits is generally the easy part of security, really. Plenty of security concepts you might want a program to have are undecidable, or undecidable at runtime.

A lot can be done using (pessimistic) static analysis, but that usually means giving up some (or in the case of total functional programming, a lot) of power or efficiency. It also tends to make programs significantly harder to write, which is really bad for adoption.

@operand

This too, yes. I wonder what the sweet spot for security would be for a really tiny language that is easy to implement and learn, but has good security properties for dealing with arbitrary code that could have come from 4chan?

I'm thinking of something like eg Jupyter Notebook, but for small local apps, and the code might be on some blockchain-y thing, which means, good lord, it might have come from anywhere, and be extremely troll-y.... how can a language best cope with such code?

@natecull Btw have you heard about Total Functional Programming? It's a pretty good approximate solution to The Halting Problem!

But to your core points, agreed. I prefer to run clientside apps, even if I end up in debates over what form that should take.

@alcinnz @natecull that is a new one. Have heard of pure functional Programming, though.

@sektor In a Haskell-like language you can require recursion to operate on subfields of the input arguments, require Divide&Conquer algorithms to have a divide step.

Also it usually enforces pattern matching to be complete to prevent crashes...

Similar approaches can be done for other functional languages.

@natecull

@alcinnz @sektor

That sounds cool!

I want to be able to do that sort of thing at runtime, though. With "compilation" as just another function I can run data through.

@alcinnz

I've heard of TFA, but I kind of think that partial functions are too useful to give up.. but hard resource limits on each function call are I think part of what's needed to make any system secure. If a recursive call can endless loop or do a giant memory leak, that's usually not helpful. We particularly don't want code we downloaded off the Internet exceeding the CPU or RAM or network allowance we gave it.

@natecull What about emulators? They run games/homebrew that the developer may not know about, but it's okay in that sandboxed (hopefully) location.

@devinprater

Right. Emulators are good because they're not subject to the (pure) Halting Problem, because it's knowable what the emulator can (and especially what it can't) do.

If you have some kind of emulator or debugging mode or kernel or hypervisor, you're no longer an unrestricted Turing Machine scrolling off to infinity. The computation CAN and WILL halt because the outermost loop will go 'nope, that's enough CPU cycles for you' and pull the brakes.

@natecull
>The Halting Problem only applies if you're doing unrestricted self-modifying code with GOTOs everywhere.
It also applies to the lambda calculus.
On the other hand, actual computers are finite state machines, not turing machines, so their halting problems are actually decideable. If you give every app some kind of super-simplified state machine for the system which it manipulates, you can pretty easily sidestep these issues (I believe this is seL4's approach)

@natecull Yeah, 100%.

Side-channel attacks aside (because I'm not up to date on the state-of-the-art wrt either the attacks or mitigations), I feel like language- or module-level capabilities are the only way to get anywhere close to the granularity that I'm really looking for in a system like this.

Traditional sandboxing can be restrictive to the point of uselessness, but I also don't want to live in a world where any code execution is radioactively dangerous.

@jfred

Yeah, capabilities seem like the next step forward (back to the 1980s, but at least it's an advance from the 1970s kind of model we still have in common use today).

I don't know quite what it is that I want, but I want assurances that code I download:

* can't read any of my data I didn't give it specific (recursive, but sensible) rights to read

* can't send that data to places I'm not happy for it to be sent

* can't change my system in ways I didn't expect it to be changed.

@jfred

I think that means that the OOP idea of "message sending" needs very strict restrictions on it. Down at the language runtime level, I think.

This was the trap that Microsoft fell into with VBA macros. Any document could tell your whole computer to do anything, including ridiculously destructive things, and then it tried to layer restrictions over the top of that.

But there was no reason that a "document" should've been able to SEE your "whole computer" object in the first place.

@natecull Yeah. I don't know how you'd get there from here, given our current computing systems really assume a heterogeneous language ecosystem with C as the common lingua franca, and C can't enforce things like that.

Maybe the answer is to rebuild on top of something that can, Smalltalk-style? (Or maybe something like WASM/WASI... less fine-grained but it's still doing capabilities at the module level, and seems like a smaller lift from where we are now.)

@natecull Oh how I want to see what we could have had if the industry had branched off at Smalltalk rather than UNIX though.

It strikes me that what was shown in this video is 1) more impressive than much of what we do on PCs today and 2) could all be done without ambient authority.

youtube.com/watch?v=AnrlSqtpOk

@jfred

Yeah, I think the big problem with capability security has been how to make it fast.

The smaller the boundaries of trust become, the slower everything gets as the system has to do checks every time a computation crosses a trust boundary.

This is becoming a real problem now that the Internet means we can pull tiny chunks of code from anywhere, like at the function level with Javascript and npm.

@jfred

And yeah I think we can draw a direct line from "C, Unix and the Internet" being a kind of trinity that sold the concept that the natural boundary of encapsulation was "the server" with "packets, streams, documents" being the communication between them.

This has led directly to our modern concepts of VM, Cloud (a cluster of VMs), and Container (as a sort of virtualised VM).

If we'd started with "objects" rather than "servers", the Web would have developed very differently.

@natecull Well in the case of Javascript in particular, isn't that kind of already happening in the form of variable lookups? It's running on a runtime that can enforce code only having access to what's in its environment. (In practice right now you'll almost always have dangerous stuff in your environment, but that doesn't have to be so.)

Re: native code, yeah, you're right. I think that's what wasm nanoprocesses are exploring. Don't know if it'll be fast enough to build an OS on though :)

@jfred

but what if you could have a WASM OS tho........... O_O

Javascript is doing its best, yes. It just seems a very large language at the moment and its security boundaries are, um, still mostly adapted for client-server work. They really really assume that "the DNS Domain" is the trust boundary which is not good if you don't own a DNS Domain or want one to even be involved.

@natecull Yeah, the point just being that I don't think capability-style checks in a managed language would necessarily make things any slower than they are now, because it's just normal variable scope.

And WASM/WASI sure would be an interesting foundation for an OS, if only because they seem to be going with a capability-style interface from the start. I have no idea how feasible that actually is though :P

Sign in to participate in the conversation
Mastodon

The original server operated by the Mastodon gGmbH non-profit