←back to thread

2071 points K0nserv | 1 comments | | HN request time: 0s | source
Show context
zmmmmm ◴[] No.45088995[source]
> In this context this would mean having the ability and documentation to build or install alternative operating systems on this hardware

It doesn't work. Everything from banks to Netflix and others are slowly edging out anything where they can't fully verify the chain of control to an entity they can have a legal or contractual relationship with. To be clear, this is fundamental, not incidental. You can't run your own operating system because it's not in Netflix's financial interest for you to do so. Or your banks, or your government. They all benefit from you not having control, so you can't.

This is why it's so important to defend the real principles here not just the technical artefacts of them. Netflix shouldn't be able to insist on a particular type of DRM for me to receive their service. Governments shouldn't be able to prevent me from end to end encrypting things. I should be able to opt into all this if I want more security, but it can't be mandatory. However all of these things are not technical, they are principles and rights that we have to argue for.

replies(38): >>45089166 #>>45089202 #>>45089284 #>>45089333 #>>45089427 #>>45089429 #>>45089435 #>>45089489 #>>45089510 #>>45089540 #>>45089671 #>>45089713 #>>45089774 #>>45089807 #>>45089822 #>>45089863 #>>45089898 #>>45089923 #>>45089969 #>>45090089 #>>45090324 #>>45090433 #>>45090512 #>>45090536 #>>45090578 #>>45090671 #>>45090714 #>>45090902 #>>45090919 #>>45091186 #>>45091432 #>>45091515 #>>45091629 #>>45091710 #>>45092238 #>>45092325 #>>45092412 #>>45092773 #
josephg ◴[] No.45089489[source]
My parents are getting old and they aren't tech savvy. The missing piece here is that I want my parents to have a computer they can safely do their banking on, without leaving them vulnerable to scams and viruses and the like. I like that they have iphones. Doing internet banking on their phone is safer than doing it on their desktop computer. Why is that?

The reason is that the desktop PC security model is deeply flawed. In modern desktop operating systems, we protect user A from user B. But any program running on my computer is - for some reason - completely trusted with my data. Any program I run is allowed to silently edit, delete or steal anything I own. Unless you install special software, you can't even tell if any of this is happening. This makes every transitive dependency of every program on your computer a potential attack vector.

I want computers to be hackable. But I don't also want my computer to be able to be hacked so easily. Right now, I have to choose between doing banking on my (maybe - hopefully - safe) computer. Or doing banking on my definitely safe iphone. What a horrible choice.

Personally I think we need to start making computers that provide the best of both worlds. I want much more control over what code can do on my computer. I also want programs to be able to run in a safe, sandboxed way. But I should be the one in charge of that sandbox. Not Google. Definitely not Apple. But there's currently no desktop environment that provides that ability.

I think the argument against locked down computers (like iphones and androids) would be a lot stronger if linux & friends provided a real alternative that was both safe and secure. If big companies are the only ones which provide a safe computing experience, we're asking for trouble.

replies(21): >>45089546 #>>45089576 #>>45089598 #>>45089602 #>>45089643 #>>45089690 #>>45089745 #>>45089884 #>>45090077 #>>45090112 #>>45090128 #>>45090605 #>>45090660 #>>45091074 #>>45091275 #>>45091454 #>>45091793 #>>45092007 #>>45092495 #>>45092746 #>>45114735 #
matheusmoreira ◴[] No.45089690[source]
> think of the elderly

This stuff is not just for the elderly and computer illiterate. It's for you as well. You think they're going to stop?

You're giving up freedom for safety. You will have neither.

replies(1): >>45089976 #
josephg ◴[] No.45089976[source]
> It's for you as well. You think they're going to stop?

No! Which is why I don't want every npm package I install to have unfettered access to my internet connection and to access all my files. If this is being exploited now, I might not even know! How sloppy is that!

> You're giving up freedom for safety.

At the limit, sure, maybe there are tradeoffs between freedom and security. But there's lots of technical solutions that we could build right now that give a lot more safety without losing any freedom at all.

Like sandboxing applications by default. Applications should by default run on my computer with the same permissions as a browser tab. Occasionally applications need more access than that. But that should require explicit privilege escalation rather than being granted to all programs by default. (Why do I need to trust that spotify and davinci resolve won't install keyloggers on my computer? Our computers are so insecure!)

Personally I'd like to see all access to the OS happen through a capability model. This would require changes in the OS and in programming languages. But the upside is it would mean we could fearlessly install software. And if you do it right, even `npm install` could be entirely safe. Here's how we do it: First, all syscalls need to pass unforgable capability tokens. (Eg SeL4). No more "stringy" syscalls. For safe 3rd party dependencies, inside processes we first make an "application capability" that is passed to main(). 3rd party libraries don't get access to any OS objects at all by default. But - if you want to use a 3rd party library to do something (like talk to redis), your program crafts a capability token with access to that specific thing and then passes it to the library as an argument.

Bad:

    // Stringy API. Redis client can do anything.
    redisClient.connect("127.0.0.1", 6379)
Good:

    redisConnCap = systemCap.narrow(TCPConnect, "127.0.0.1", 6379)
    redisClient.connect(redisConnCap)
This way, the redis library can only make outgoing connections on the specified TCP port. Everything else - including the filesystem - is off limits to this library.

This would require some PL level changes too. Like, it wouldn't be secure if libraries can access arbitrary memory within your process. In a language like rust we'd need to limit unsafe code. (And maybe other stuff?). In GC languages like C# and javascript its easier - though we might need to tweak the standard libraries. And ban (or sandbox) native modules like napi and cgo.

replies(3): >>45090115 #>>45090658 #>>45118021 #
Earw0rm ◴[] No.45090658[source]
IMO what's needed is less per-app sandboxing, and more per-context.

Think user accounts but for task classes.

If I'm doing development work, I want to be able to chain together a Frankenstein of apps, toolchain, API services and so on, with full access to everything else in that specific context.

But that doesn't need visibility of my email, my banking and accounting software should have visibility to/from neither, and random shareware apps, games and movies should run, like you say, with a browser tab level of permission.

Making this work in practice while keeping performance maximised is harder than it sounds, preventing leaks via buffers or timing attacks of one sort or another (if apps can take screenshots, game over).. for now I use user accounts, but this is becoming less convenient as the major desktop OS and browser vendors try to force tying user accounts to a specific online identity.

replies(1): >>45090811 #
1. josephg ◴[] No.45090811{3}[source]
> IMO what's needed is less per-app sandboxing, and more per-context.

I think you could do this with capabilities!

The current model makes of security implicit, where an application can make any syscall it wants and its up to the OS to (somehow) figure out if the request is valid or not. Capabilities - on the other hand - restrict access of a resource to the bearer of a certain token. The OS knows that by invoking capability X, the bearer can make requests to a certain resource / account / file / whatever. (Think of it like unix file descriptors. You just call write(1, ...) and the OS knows what file you're writing to, and what your access to that file is.)

There's lots of ways to use capabilities to build the sort of frankenstein app you're talking about using caps. Eg, you could have a supervisor task (maybe the desktop or a script or something) that has a capability for everything the user cares about. It can create sub-capabilities which just have access to specific network ports / files / accounts / whatever. It launches subprocesses and hands the right capabilities to the right sub processes. The sub processes don't even need to know what the capability they were given connects to. They just need to know - for example - that reading from the capability gives it the data it expects to receive. Then you can do all the routing & configuration from the supervisor task.

Because all the sub processes only have the specific capabilities that were passed to them, the security surface area is automatically minimised.

SeL4 shows that you can do this without losing much performance. (In SeL4, the IPC overhead is tiny.) But as I said upthread, I'm sure there's also ways to design our programming languages to allow within-process isolation. So, for example, you can call the leftpad package without giving it capabilities held by other parts of the same program.

Capabilities can also make it easy to virtualise filesystems, the network, and so on. Or to do interdiction - and snoop on the messages being sent. Its easy because you can just make virtual network / filesystem / whatever capabilities and pass those to subprocesses.