5 ms·

> I just wonder why the author of this page does not disclose his name... > And even hides this from the whois info. The registrant country is listed as Franc

by dpwm 8y ago

> I just wonder why the author of this page does not disclose his name... > And even hides this from the whois info. The registrant country is listed as France and the registrar is OVH. They are simply adhering to the GDPR. I have domains that have been like this since May, even though I would be quite happy to have everything public. > This could have been written by a person with a grudge for all I am concerned. Your comment could have been written by somebody with a grudge against the person you are claiming could have had a grudge for all I am concerned. A vested interest can make a difference, but I don't really see how any of the points are hard to verify. Does this being written by a person with a grudge really negate the points made? - Flatpak is claiming to be secure - Flatpak is sandboxing apps with full access to your home directory. (What is the worst thing that an app can do? Nuke your home directory or run malicious software. The sandboxing here does little to mitigate this.) - Apps are not being updated as quickly as their distribution repository counterparts. - At some point in its past, a (presumably) privileged component with permissions to setuid did not check that it wasn't blindly copying setuid. It seems to me that this is more about easy delivery of software with a security claim that is arguably pretty weak at the moment against likely attack vectors. I can't see that changing without first thinking of what you're actually sandboxing for. There are already software delivery systems, such as 0install and appimage, that do not make claims about being sandboxed and yet provide a similar (or greater in the setuid case) level of security for the main threats. I find it hard to understand who the project is for. If you're a developer on your own machine then using your distro's package manager is probably more secure. If you're a sysadmin, letting users use flatpak serves only to increase the attack surface for privilege escalation.

toyg 8y ago
The problem is that distro package managers are many and often complex to satisfy, which is one of the reasons people don’t develop “real” desktop software for Linux. The new generation of installers (flatpak, snap etc) takes a cross-distro approach that is supposed to result, more or less, in “package once, run everywhere”: you build your app in a certain way and every distro should be able to run it, regardless of package managers. It’s basically a way to offload the compatibility headaches to flatpak developers and distribution builders. Obviously that approach works only if flatpak does actually get good support in all distributions and becomes a de-facto standard, which is a challenge because there are many competitors (Ubuntu Snap being the most relevant one). If it remains just a glorified rpm (i.e. a redhat-specific tool), then there is no point.
- dpwm 8y ago
  > The problem is that distro package managers are many and often complex to satisfy, which is one of the reasons people don’t develop “real” desktop software for Linux. If by real you mean the kind of proprietary {ad,spy,toolbar}-ware encrusted "real" desktop software that Windows has become notorious for then I think we may be better off without it. If you're talking about OSX, then I think you're missing that it's a market skewed towards those with the money and will to pay for proprietary software. Plenty of people are developing "real" desktop software for Linux. > The new generation of installers (flatpak, snap etc) takes a cross-distro approach that is supposed to result, more or less, in “package once, run everywhere”: you build your app in a certain way and every distro should be able to run it, regardless of package managers. It’s basically a way to offload the compatibility headaches to flatpak developers and distribution builders. This isn't novel. 0install and AppImage have been around for a while now. What is novel is that Flatpak combines this with sandboxing that doesn't really do so much to mitigate against any vulnerabilities that aren't in the kernel. I actually think they've got the sandboxing right, in that they are really starting with minimum privileges and adding only what is needed.[0] The problem, as they state, is that it is fine to drop all privileges for something like a single-player game, but it sucks for a file manager. At least according to their wiki, they're already doing most of what you could imagine you could improve on the sandboxing. [0] It's always this interaction with the outside world that breaks sandboxing. It's rather easy to make a sandbox that runs as nobody and has no privileges and no capabilities and no file access. It's a bit harder to make something which has any of those things in a way which the user can grant sensible permissions. It sounds like in Portals [1] the Flatpak team have gone in pretty much the only workable direction, although the Wiki is hopefully out of date and there are more portals. The problem they will have found is that to package anything useful and get feedback and validation requires that they implement the most difficult bits first. So I suspect the situation is "secure file picker is coming". Sandboxing is a lot of work, not in the closing down but in the opening up. One of the more innovative approaches is to be found in Sandstorm [2]. Although marketed as a way to run web applications on your own server easily, it is actually a tight sandbox built on top of Cap'n Proto, which means that E-style capability-based RPC is intrinsic. Sandboxed apps have no access to anything, cutting down on kernel attack space. The only connection to the outside world is through a UNIX socket file descriptor opened by the supervisor. The capabilities-based security model mean that a sandboxed app could request the ability to connect to "drive.google.com", or even a specific URL. This could also be passed to other apps through the supervisor, subject to user approval. Capabilities can be stored on disk to be later restored from the supervisor. In Sandstorm the UI for granting capabilities between apps is working, but progress has slowed as the team have all had to find other ways to pay the bills. > Obviously that approach works only if flatpak does actually get good support in all distributions and becomes a de-facto standard, which is a challenge because there are many competitors (Ubuntu Snap being the most relevant one). If it remains just a glorified rpm (i.e. a redhat-specific tool), then there is no point. I think the problem is that if your target is casual users, they're not going to necessarily understand the nuances and limitations of the sandboxing. [0] https://github.com/flatpak/flatpak/wiki/Sandbox https://github.com/flatpak/flatpak/wiki/Sandbox [1] https://github.com/flatpak/flatpak/wiki/Portals https://github.com/flatpak/flatpak/wiki/Portals [2] https://sandstorm.io/how-it-works#capabilities https://sandstorm.io/how-it-works#capabilities
gbraad 8y ago
Flatpak does not claim to be secure. This is also clearly stated in the FAQ. They provide a means of separation of applications. Sandboxing is not per se a form of security, just like this was with Docker in the 'early days'.

by dpwm 8y ago

toyg 8y ago

The problem is that distro package managers are many and often complex to satisfy, which is one of the reasons people don’t develop “real” desktop software for Linux. The new generation of installers (flatpak, snap etc) takes a cross-distro approach that is supposed to result, more or less, in “package once, run everywhere”: you build your app in a certain way and every distro should be able to run it, regardless of package managers. It’s basically a way to offload the compatibility headaches to flatpak developers and distribution builders. Obviously that approach works only if flatpak does actually get good support in all distributions and becomes a de-facto standard, which is a challenge because there are many competitors (Ubuntu Snap being the most relevant one). If it remains just a glorified rpm (i.e. a redhat-specific tool), then there is no point.

dpwm 8y ago
> The problem is that distro package managers are many and often complex to satisfy, which is one of the reasons people don’t develop “real” desktop software for Linux. If by real you mean the kind of proprietary {ad,spy,toolbar}-ware encrusted "real" desktop software that Windows has become notorious for then I think we may be better off without it. If you're talking about OSX, then I think you're missing that it's a market skewed towards those with the money and will to pay for proprietary software. Plenty of people are developing "real" desktop software for Linux. > The new generation of installers (flatpak, snap etc) takes a cross-distro approach that is supposed to result, more or less, in “package once, run everywhere”: you build your app in a certain way and every distro should be able to run it, regardless of package managers. It’s basically a way to offload the compatibility headaches to flatpak developers and distribution builders. This isn't novel. 0install and AppImage have been around for a while now. What is novel is that Flatpak combines this with sandboxing that doesn't really do so much to mitigate against any vulnerabilities that aren't in the kernel. I actually think they've got the sandboxing right, in that they are really starting with minimum privileges and adding only what is needed.[0] The problem, as they state, is that it is fine to drop all privileges for something like a single-player game, but it sucks for a file manager. At least according to their wiki, they're already doing most of what you could imagine you could improve on the sandboxing. [0] It's always this interaction with the outside world that breaks sandboxing. It's rather easy to make a sandbox that runs as nobody and has no privileges and no capabilities and no file access. It's a bit harder to make something which has any of those things in a way which the user can grant sensible permissions. It sounds like in Portals [1] the Flatpak team have gone in pretty much the only workable direction, although the Wiki is hopefully out of date and there are more portals. The problem they will have found is that to package anything useful and get feedback and validation requires that they implement the most difficult bits first. So I suspect the situation is "secure file picker is coming". Sandboxing is a lot of work, not in the closing down but in the opening up. One of the more innovative approaches is to be found in Sandstorm [2]. Although marketed as a way to run web applications on your own server easily, it is actually a tight sandbox built on top of Cap'n Proto, which means that E-style capability-based RPC is intrinsic. Sandboxed apps have no access to anything, cutting down on kernel attack space. The only connection to the outside world is through a UNIX socket file descriptor opened by the supervisor. The capabilities-based security model mean that a sandboxed app could request the ability to connect to "drive.google.com", or even a specific URL. This could also be passed to other apps through the supervisor, subject to user approval. Capabilities can be stored on disk to be later restored from the supervisor. In Sandstorm the UI for granting capabilities between apps is working, but progress has slowed as the team have all had to find other ways to pay the bills. > Obviously that approach works only if flatpak does actually get good support in all distributions and becomes a de-facto standard, which is a challenge because there are many competitors (Ubuntu Snap being the most relevant one). If it remains just a glorified rpm (i.e. a redhat-specific tool), then there is no point. I think the problem is that if your target is casual users, they're not going to necessarily understand the nuances and limitations of the sandboxing. [0] https://github.com/flatpak/flatpak/wiki/Sandbox https://github.com/flatpak/flatpak/wiki/Sandbox [1] https://github.com/flatpak/flatpak/wiki/Portals https://github.com/flatpak/flatpak/wiki/Portals [2] https://sandstorm.io/how-it-works#capabilities https://sandstorm.io/how-it-works#capabilities

gbraad 8y ago

Flatpak does not claim to be secure. This is also clearly stated in the FAQ. They provide a means of separation of applications. Sandboxing is not per se a form of security, just like this was with Docker in the 'early days'.