5 ms·

Is the sandboxing of flatpak more or less secure than docker?

Kalium 8y ago
As I understand it, from reading this page it doesn't actually matter much how secure the sandbox is as many applications effectively disable it.
- briffle 8y ago
  And many docker users run privileged containers, because then they don't need to troubleshoot permissions.. It doesn't meant the underlying system is flawed, because people take the lazy way around it. I'm thinking of all the blogs back a few years ago for setting up things on Centos. Step 1, disable SELinux.. That was never recommended, but the blog writers didn't want to go into details about how to manage selinux, or couldn't understand it.
  - Kalium 8y ago
    You're right! It's not the fault of the underlying system, it's the fault of the lazy people who work around it trivially. With that said, some people might consider a system that is much easier to trivially work around than to use properly is one possessed of a wonderful, glorious, bountiful collection of opportunities to improve its design. Such systems are not bad! Not by any means! They just could, perhaps, be somewhat better. All of that said, I do think a sandbox-based system probably shouldn't allow things inside the sandbox to say "Don't sandbox me bro". That seems less than maximally wise, even if it does also seem super convenient.
  - the_duke 8y ago
    I almost never had to run a privileged container, and I avoid it whenever possible. As far as I have seen, privileged container use is rare. What lead you to the assumption that it isn't?
    - cyphar 8y ago
      It should also be noted that bind-mounting docker.sock is equivalent (or much worse -- it's easier to exploit at least) to using privileged containers, and an exceptionally large number of people do this (you see it in many blog posts and project installation scripts).
lvh 8y ago
They use a lot of similar techniques. One big difference is that docker uses user namespaces and flatpak does not. I'n not sure about the reasoning, but it's probably a combo of "not trusting user namespaces" (disagree) and user namespaces requiring privileges to use. It sounds like the bigger issue isn't that the underlying technologies are fundamentally better or worse, but that the de facto configurations are worse. In particular, the median docker container can not write to my home directory. The median flatpak can. Despite the ordering, the "no updates" seems like a way worse issue than the "most of the sandboxing is ineffective". It seems pretty clear to me that a lot of apps need wide access and the first person who does a great job at that will do us all a big security favor but we're not there yet in terms of UX. Sometimes I really want my text editor to edit my bashrc. Maybe that should require a privilege escalation, that's fine.
- arthurfm 8y ago
  > I'n not sure about the reasoning, but it's probably a combo of "not trusting user namespaces" (disagree) and user namespaces requiring privileges to use. binctr looks like an interesting solution to tackle this issue. [1] https://blog.jessfraz.com/post/getting-towards-real-sandbox-containers/ https://blog.jessfraz.com/post/getting-towards-real-sandbox-... [2] https://github.com/genuinetools/binctr https://github.com/genuinetools/binctr [3] https://news.ycombinator.com/item?id=18180276 https://news.ycombinator.com/item?id=18180276
  - cyphar 8y ago
    Or https://rootlesscontaine.rs/ https://rootlesscontaine.rs/ [1]. runc has had upstream support for this for quite a while (binctr predates it by a bit, but the LXC support for it predates all of this by several years). If you want to run this in production, please use this -- or LXC -- rather than the PoC that Jess wrote a few years ago. umoci[2] also has rootless support (though it doesn't use user namespaces) for image manipulation (extraction and diff generation). I worked quite a bit on getting this userspace stuff together (though of course the kernel work was done by much more clever people than myself :P). [1]: https://github.com/rootlesscontainers https://github.com/rootlesscontainers [2]: https://github.com/openSUSE/umoci https://github.com/openSUSE/umoci
blattimwind 8y ago
What's better to hold water, a colander or a sieve? Which is to say, when you hand out the privileges laid out in the article, it really doesn't matter what software you used to whitelist "every thing".

As I understand it, from reading this page it doesn't actually matter much how secure the sandbox is as many applications effectively disable it.

briffle 8y ago
And many docker users run privileged containers, because then they don't need to troubleshoot permissions.. It doesn't meant the underlying system is flawed, because people take the lazy way around it. I'm thinking of all the blogs back a few years ago for setting up things on Centos. Step 1, disable SELinux.. That was never recommended, but the blog writers didn't want to go into details about how to manage selinux, or couldn't understand it.
- Kalium 8y ago
  You're right! It's not the fault of the underlying system, it's the fault of the lazy people who work around it trivially. With that said, some people might consider a system that is much easier to trivially work around than to use properly is one possessed of a wonderful, glorious, bountiful collection of opportunities to improve its design. Such systems are not bad! Not by any means! They just could, perhaps, be somewhat better. All of that said, I do think a sandbox-based system probably shouldn't allow things inside the sandbox to say "Don't sandbox me bro". That seems less than maximally wise, even if it does also seem super convenient.
- the_duke 8y ago
  I almost never had to run a privileged container, and I avoid it whenever possible. As far as I have seen, privileged container use is rare. What lead you to the assumption that it isn't?
  - cyphar 8y ago
    It should also be noted that bind-mounting docker.sock is equivalent (or much worse -- it's easier to exploit at least) to using privileged containers, and an exceptionally large number of people do this (you see it in many blog posts and project installation scripts).

lvh 8y ago

They use a lot of similar techniques. One big difference is that docker uses user namespaces and flatpak does not. I'n not sure about the reasoning, but it's probably a combo of "not trusting user namespaces" (disagree) and user namespaces requiring privileges to use. It sounds like the bigger issue isn't that the underlying technologies are fundamentally better or worse, but that the de facto configurations are worse. In particular, the median docker container can not write to my home directory. The median flatpak can. Despite the ordering, the "no updates" seems like a way worse issue than the "most of the sandboxing is ineffective". It seems pretty clear to me that a lot of apps need wide access and the first person who does a great job at that will do us all a big security favor but we're not there yet in terms of UX. Sometimes I really want my text editor to edit my bashrc. Maybe that should require a privilege escalation, that's fine.

arthurfm 8y ago
> I'n not sure about the reasoning, but it's probably a combo of "not trusting user namespaces" (disagree) and user namespaces requiring privileges to use. binctr looks like an interesting solution to tackle this issue. [1] https://blog.jessfraz.com/post/getting-towards-real-sandbox-containers/ https://blog.jessfraz.com/post/getting-towards-real-sandbox-... [2] https://github.com/genuinetools/binctr https://github.com/genuinetools/binctr [3] https://news.ycombinator.com/item?id=18180276 https://news.ycombinator.com/item?id=18180276
- cyphar 8y ago
  Or https://rootlesscontaine.rs/ https://rootlesscontaine.rs/ [1]. runc has had upstream support for this for quite a while (binctr predates it by a bit, but the LXC support for it predates all of this by several years). If you want to run this in production, please use this -- or LXC -- rather than the PoC that Jess wrote a few years ago. umoci[2] also has rootless support (though it doesn't use user namespaces) for image manipulation (extraction and diff generation). I worked quite a bit on getting this userspace stuff together (though of course the kernel work was done by much more clever people than myself :P). [1]: https://github.com/rootlesscontainers https://github.com/rootlesscontainers [2]: https://github.com/openSUSE/umoci https://github.com/openSUSE/umoci

blattimwind 8y ago

What's better to hold water, a colander or a sieve? Which is to say, when you hand out the privileges laid out in the article, it really doesn't matter what software you used to whitelist "every thing".