3 ms·

> The home OS should containerize all externally obtained binaries, assigning limited resources to them, as chosen by the user. The package distributors do not

by jabl 6y ago

> The home OS should containerize all externally obtained binaries, assigning limited resources to them, as chosen by the user. The package distributors do not get to decide what level of access do they need; from they point of view, all resources are available; but the user must be able to add limits from the other side, unbeknownst to the (potentially hostile) package distributor. The problem is that the user can't be expected to know which resources an app needs ("Hey, this thing wants to access /usr/lib/x86_64-linux-gnu/libc.so, sounds suspicious, let's deny it"), but OTOH you're fully correct that the user must have the choice to deny specific access, perhaps by giving the app fake or empty data. So I think both are needed, so honest app developers can specify a minimum set of permissions the app needs to work to reduce the havoc a programming error in the app can create, but also giving the user opportunity to limit what the app can see (the user presumably want a word processor to be able to read and write a document the user is working on at the moment, but not everything in the users home directory).

enriquto 6y ago
Sure, many resources should probably be enabled by default (e.g., read-only access to /usr/lib), or globally selected by OS profiles, for example. Apps can also declare sets of permissions that the users will be able to override as they like, and that would be really helpful. My point is that the security must not be enforced by the package distributors. This is what happens when they ship containers, as snap and the like, and it is a disgustingly wrong policy. Security must be enforced by the OS, under the total control of the user, and with reasonable defaults.
antihero 6y ago
Why not a virtual/shadow FS? The application would be given a virtual home dir, and would try to access the "~/Downloads" folder, for instance, and then this would take the form of a macOS "Firefox wants to access your downloads folder". Then, OS can easily set up a mount on the container for that folder, with restricted perms. Same with drag and drop. Data could be put into a folder in /tmp, a mount could be set up whilst it uploads your photo or whatever to Facebook, and then the mount and the temporary dir could be deleted. Having a "shadow fs" displayed to the container so it can function as if it is not in a container, but then when it wants to access the actual fs, it is done via either prebaked whitelist or user interaction/confirmation, would be great because apps would not have to be modified and security would be incredible. You could even have it write to shadow FS and that could be synced later.
- curt15 6y ago
  You've basically just described Linux mount namespaces. Flatpak and snap applications each see a virtual root directory which grants no visibility into the user's home directory by default. D-bus services called "portals" then grant access to individual files upon user consent.

by jabl 6y ago

enriquto 6y ago

Sure, many resources should probably be enabled by default (e.g., read-only access to /usr/lib), or globally selected by OS profiles, for example. Apps can also declare sets of permissions that the users will be able to override as they like, and that would be really helpful. My point is that the security must not be enforced by the package distributors. This is what happens when they ship containers, as snap and the like, and it is a disgustingly wrong policy. Security must be enforced by the OS, under the total control of the user, and with reasonable defaults.

antihero 6y ago

Why not a virtual/shadow FS? The application would be given a virtual home dir, and would try to access the "~/Downloads" folder, for instance, and then this would take the form of a macOS "Firefox wants to access your downloads folder". Then, OS can easily set up a mount on the container for that folder, with restricted perms. Same with drag and drop. Data could be put into a folder in /tmp, a mount could be set up whilst it uploads your photo or whatever to Facebook, and then the mount and the temporary dir could be deleted. Having a "shadow fs" displayed to the container so it can function as if it is not in a container, but then when it wants to access the actual fs, it is done via either prebaked whitelist or user interaction/confirmation, would be great because apps would not have to be modified and security would be incredible. You could even have it write to shadow FS and that could be synced later.

curt15 6y ago
You've basically just described Linux mount namespaces. Flatpak and snap applications each see a virtual root directory which grants no visibility into the user's home directory by default. D-bus services called "portals" then grant access to individual files upon user consent.