4 ms·

Some kind of sandboxing (mumble mumble containers) is necessary for the Linux desktop. In 2021 the security threat to a desktop user largely isn't other users o

by jabl 6y ago

Some kind of sandboxing (mumble mumble containers) is necessary for the Linux desktop. In 2021 the security threat to a desktop user largely isn't other users on the same box poking around in your files, which is what the POSIX permissions protect against, but that every process you run has full access to all your files. Meanwhile, the distro packaging process isn't keeping up with packaging all interesting FOSS out there, e.g. it has more or less completely dropped the ball on integrating with the many language-specific package managers out there like cargo, npm, pypi. And also it seems processes and workflows are stuck in the 1990'ies further preventing progress (e.g. https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/ https://michael.stapelberg.ch/posts/2019-03-10-debian-windin... ). Ironically people run more up to date FOSS on windows or macOS than on Linux, where you're stuck with the schedule of your distro. There's also the irony that some FOSS apps fund themselves by providing builds for money on the commercial app stores, but they have no way to similarly monetize Linux users (e.g. Krita). So some kind of base system + app store where the app developers can push sandboxed stuff with some automated or human curating like the mobile app stores around now looks like a reasonable model. I guess this is what flatpack and snaps are aiming for. Also, where should the line be drawn between the base and the app store apps? Presumably we don't want coreutils to come packaged as a container, but I don't have a clear answer to where the line should be.

enriquto 6y ago
> Presumably we don't want coreutils to come packaged as a container, but I don't have a clear answer to where the line should be. Nothing should come packaged as a container. 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 their 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.
- 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.
- marcthe12 6y ago
  Well the technologies behind containers can used independent of containers. For example with mount namespace you can modify filesystem layout, mem cgroups for memory limits and so on. There are 3 issues of these: 1) Several operation are root only or need user namespaces which has its own problems. 2)almost all of these operations are inherented by processor in similar manner as user of the process effectively making a need for some kind of sudo or polkit style solution. 3) some protocols and storage systems are implemented in userspace and are hard to sandbox making a need for proxy. Examples are Xorg, dbus, DNS, dconf. So proxy and policy management is kinda an issue.
viraptor 6y ago
> Presumably we don't want coreutils to come packaged as a container For base system utilities we already have sandboxing solutions. Either apparmor or selinux can do it quite well. Apparmor doesn't come with quite the number of profiles yet, but I see that my system has specific selinux labels on chsh, dmesg, hostname, and other common binaries.
eeZah7Ux 6y ago
sandboxing != containers Please stop confusing the two things. Sandboxing is about security. Containers are mainly modern chroots. > And also it seems processes and workflows are stuck in the 1990'ies further preventing progress Quite the opposite, especially in Debian. The distribution has been driving a lot of innovative projects including reproducible builds. > So some kind of base system + app store A curated archive of software, reviewed by trusted packagers and thoroughly tested by a large number of users? It's called APT and existed a decades before "app stores" > where the app developers can push sandboxed stuff No thanks, I'll never trust upstream developers to sandbox their own stuff. Too many times I run into upstream developers thinking that the end user system is their playground.

by jabl 6y ago

enriquto 6y ago

> Presumably we don't want coreutils to come packaged as a container, but I don't have a clear answer to where the line should be. Nothing should come packaged as a container. 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 their 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.

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.
marcthe12 6y ago
Well the technologies behind containers can used independent of containers. For example with mount namespace you can modify filesystem layout, mem cgroups for memory limits and so on. There are 3 issues of these: 1) Several operation are root only or need user namespaces which has its own problems. 2)almost all of these operations are inherented by processor in similar manner as user of the process effectively making a need for some kind of sudo or polkit style solution. 3) some protocols and storage systems are implemented in userspace and are hard to sandbox making a need for proxy. Examples are Xorg, dbus, DNS, dconf. So proxy and policy management is kinda an issue.

viraptor 6y ago

> Presumably we don't want coreutils to come packaged as a container For base system utilities we already have sandboxing solutions. Either apparmor or selinux can do it quite well. Apparmor doesn't come with quite the number of profiles yet, but I see that my system has specific selinux labels on chsh, dmesg, hostname, and other common binaries.

eeZah7Ux 6y ago

sandboxing != containers Please stop confusing the two things. Sandboxing is about security. Containers are mainly modern chroots. > And also it seems processes and workflows are stuck in the 1990'ies further preventing progress Quite the opposite, especially in Debian. The distribution has been driving a lot of innovative projects including reproducible builds. > So some kind of base system + app store A curated archive of software, reviewed by trusted packagers and thoroughly tested by a large number of users? It's called APT and existed a decades before "app stores" > where the app developers can push sandboxed stuff No thanks, I'll never trust upstream developers to sandbox their own stuff. Too many times I run into upstream developers thinking that the end user system is their playground.