3 ms·

I agree that containers are easier to manage than SELinux, but still not easy enough. Linux provides many low level primitives for restricting applications and

by ximm 4y ago

I agree that containers are easier to manage than SELinux, but still not easy enough. Linux provides many low level primitives for restricting applications and SELinux, Apparmor, Docker, Flatpak, and systemd all provide high level abstractions for those. But IMHO none of them really finds a sweet spot between flexibility and usability. `systemd-analyze security` for example lists 80 (!) different settings, even though some of them are very high level such as `ProtectSystem`. Containers have made the conceptual shift from allow/deny to isolate/share. Somehow this feels better even though it is effecitvely the same. I am still waiting for an abstraction that uses all the low level features and wraps them in a high-level interface that puts usability front and center. I am not sure if this is even possible though because many applications are not built with sandboxing in mind. Adding another file somewhere on the system that needs to be accessed is not considered a breaking change by most. So maybe we need a more fundamental shift.

zozbot234 4y ago
> I am still waiting for an abstraction that uses all the low level features and wraps them in a high-level interface that puts usability front and center. Bubblewrap? FlatPak's sandboxing features are built on it already.
tinco 4y ago
In my opinion, if an application requires more access than a docker container gives by default, then that application should probably just run in a VM. If the application needs more access because it needs to manage or control some hardware, then it should be tailored to the O/S and have a small core service that runs naked under systemd or whatever. If fancy management of that core service is needed, it can expose a port that an application can talk to, that's safely isolated in a docker container. Maybe that's just daydreaming about a perfect world, but I agree that it should be easy to reason about the access levels.
- ximm 4y ago
  What about an application like vim? It should be able to access any file I pass that is explicitly opened, but not much more. That is hard to express with current tooling.
  - tinco 4y ago
    You shouldn't run an application like vim in Docker. Unless your server is running Vim as some sort of service, in which case it should only open files in a volume you bound to it. Vim is exactly the kind of application you would run in a virtual machine.
  - legalcorrection 4y ago
    You could do it with a file picker API that opened an out-of-process file picker. I'm pretty sure this is how WinRT works. Would be tricky for a purely command line workflow, but very doable with a GUI.
    - iggldiggl 4y ago
      Even file picker APIs are severely lacking with regards to any multi-file filetypes, where opening one file means having to subsequently access further additional files, too (but which files exactly cannot necessarily defined in advance because it depends on the contents of the initially opened file).
  - tadfisher 4y ago
    You are describing the Flatpak security model. Flatpak was invented for interactive applications like this.

by ximm 4y ago

zozbot234 4y ago

> I am still waiting for an abstraction that uses all the low level features and wraps them in a high-level interface that puts usability front and center. Bubblewrap? FlatPak's sandboxing features are built on it already.

tinco 4y ago

In my opinion, if an application requires more access than a docker container gives by default, then that application should probably just run in a VM. If the application needs more access because it needs to manage or control some hardware, then it should be tailored to the O/S and have a small core service that runs naked under systemd or whatever. If fancy management of that core service is needed, it can expose a port that an application can talk to, that's safely isolated in a docker container. Maybe that's just daydreaming about a perfect world, but I agree that it should be easy to reason about the access levels.

ximm 4y ago
What about an application like vim? It should be able to access any file I pass that is explicitly opened, but not much more. That is hard to express with current tooling.
- tinco 4y ago
  You shouldn't run an application like vim in Docker. Unless your server is running Vim as some sort of service, in which case it should only open files in a volume you bound to it. Vim is exactly the kind of application you would run in a virtual machine.
- legalcorrection 4y ago
  You could do it with a file picker API that opened an out-of-process file picker. I'm pretty sure this is how WinRT works. Would be tricky for a purely command line workflow, but very doable with a GUI.
  - iggldiggl 4y ago
    Even file picker APIs are severely lacking with regards to any multi-file filetypes, where opening one file means having to subsequently access further additional files, too (but which files exactly cannot necessarily defined in advance because it depends on the contents of the initially opened file).
- tadfisher 4y ago
  You are describing the Flatpak security model. Flatpak was invented for interactive applications like this.