3 ms·

> Adding permissions is a reasonable step, but I don't think it solves the problem. We know, it's very hard to get granularity right with permission systems and

> Adding permissions is a reasonable step, but I don't think it solves the problem. We know, it's very hard to get granularity right with permission systems and there is a strong temptation to just give everything all permissions. A lot of that stems from permissions systems being implemented outside of the code they constrain. In theory a compiler knows every reachable system call and all points of data input that could reach them, and as such it could constrain the program's capabilities accordingly. In fact, compilers already do this for control flow integrity - it would just be a more advanced system. > What happened if an update requests a new permission? It's going to depend on the system. For browser extensions the new permission means a new prompt, so you'd get a CI failure until a human updated a lockfile. > Also, how would that have prevented the current situation? Infinite loops are famously hard to detect and prevent automatically. It really depends on the system. You could have a CPU capability that restricts cycles or forces preemption, etc. I'm not saying you can solve literally all security problems but you can reduce risk considerably. If "infinite loop" is the scariest thing a dependency can do we're in a pretty good position. An unconditional infinite loop should break your CI tests.

michaelt 5y ago
> In theory a compiler knows every reachable system call and all points of data input that could reach them Sorta yes, sorta no. Imagine I'm making a chat client, and I want users to be able to drag and drop images to share. But the OS doesn't have an "open drag-and-dropped file, extension .png or .jpg" function call, it only has "open file" which lets me open ~/.ssh/id_rsa too. Or if I'm making a web browser and I want to support U2F tokens. But there's no OS "talk to U2F token" call - the browser needs access to the system calls for "talk to arbitrary USB devices". Sandboxing PC software is tough.
- naasking 5y ago
  > But the OS doesn't have an "open drag-and-dropped file, extension .png or .jpg" function call, it only has "open file" which lets me open ~/.ssh/id_rsa too. A programming language doesn't have to expose system calls directly. It arguably it shouldn't, in fact, for exactly this reason.
- staticassertion 5y ago
  If you end up with "X can open any file" that's something that's worth noting to a consumer. The sandbox capabilities don't have to be perfect in order to expose a scary situation. Further, you can restrict a process to only open specific files in a number of ways on Linux, including based on path. There's room for improvement, though.

michaelt 5y ago

> In theory a compiler knows every reachable system call and all points of data input that could reach them Sorta yes, sorta no. Imagine I'm making a chat client, and I want users to be able to drag and drop images to share. But the OS doesn't have an "open drag-and-dropped file, extension .png or .jpg" function call, it only has "open file" which lets me open ~/.ssh/id_rsa too. Or if I'm making a web browser and I want to support U2F tokens. But there's no OS "talk to U2F token" call - the browser needs access to the system calls for "talk to arbitrary USB devices". Sandboxing PC software is tough.

naasking 5y ago
> But the OS doesn't have an "open drag-and-dropped file, extension .png or .jpg" function call, it only has "open file" which lets me open ~/.ssh/id_rsa too. A programming language doesn't have to expose system calls directly. It arguably it shouldn't, in fact, for exactly this reason.
staticassertion 5y ago
If you end up with "X can open any file" that's something that's worth noting to a consumer. The sandbox capabilities don't have to be perfect in order to expose a scary situation. Further, you can restrict a process to only open specific files in a number of ways on Linux, including based on path. There's room for improvement, though.