Comment by josephg
1 month ago
> 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.
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.
> 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.
> 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.
Everything you have suggested in this post takes away freedom. There is no solution that doesn't take away freedom / your control. There is always a trade off.
> 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!)
This already exists on Linux.
I run Discord/Slack in Flatpak. Out of the box the folders and clipboard permissions are restricted. Only the ~/Downloads folder on my PC is accessible to Discord/Slack. You can't drag and drop things into these apps. Which makes sharing content a PITA.
If you don't want to worry about things like keyloggers, you should run an open source OS and use open source programs where you can verify that there are no key loggers. You should also make sure you find out what firmware your keyboard is using (many keyboards themselves have complex micro controllers on them that can be programmed).
> Everything you have suggested in this post takes away freedom. There is no solution that doesn't take away freedom / your control. There is always a trade off.
Huh? In what way does application sandboxing take away my freedom? What can I do today that I can't do with a sandbox-everything-by-default model?
In my mind, it gives me (the user) more freedom because I can run any program I want without fear.
> I run Discord/Slack in Flatpak. Out of the box the folders and clipboard permissions are restricted. Only the ~/Downloads folder on my PC is accessible to Discord/Slack. You can't drag and drop things into these apps. Which makes sharing content a PITA.
Cool! Yeah this is the sort of thing I want to see more of. The drag & drop problem is technically solvable - it just sounds like they haven't solved it yet. (Capabilities would be a great solution for this.. just sayin!)
> Huh? In what way does application sandboxing take away my freedom? What can I do today that I can't do with a sandbox-everything-by-default model?
I've just explained that sand-boxing causes issues with file access, clipboard sharing etc.
Every hoop you add in makes it more difficult for the user to gain back control, even if that is modifying permissions yourself. Most people will just remove permissions out of annoyance.
If you remove control, you remove people's freedom.
> In my mind, it gives me (the user) more freedom because I can run any program I want without fear.
Any security mechanism has a weakness or it will be bypassed by other means. So all this will give you a false sense of security.
The moment you think you are safe. Is when you are most unsafe.
> Cool! Yeah this is the sort of thing I want to see more of. The drag & drop problem is technically solvable - it just sounds like they haven't solved it yet. (Capabilities would be a great solution for this.. just sayin!)
I don't. It is a PITA. Eventually people just turn it off. I did.
The reality is that if you want ultimate security you have to make a trade offs. Pretending you can make some theoretical system where those trade off don't exists just isn't realistic.
18 replies →
It's not a technical problem. It's a social, legal and business problem.
Computers are subversive. They have the power to not only wipe out entire sectors of the economy but also defeat governments and militaries. If you let people run software freely, they can give themselves the power to do things like block ads and copy artificially scarce data at zero cost, directly impacting the bottom line of corporations. And that's when they don't run cryptography, cryptocurrency and anonymization software to escape government control.
So these businesses and governments have every reason in the world to usurp control of your computer. They want computers to only run software that's been authorized by them, so that you can do nothing that harms their interests.
It's not your computer, it's theirs, they're just letting you use it, and only if you follow company and government policy. And it's not at all about your security against external attackers in general, it's about their security against you.
It's got nothing at all to do with "capabilities". It's got everything to do with putting you in digital shackles so that you are forced to live in a dystopian cyberpunk technofeudalist digital fiefdom as a serf who pays and consumes in perpetuity.