4 ms·

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 pr

by 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
Jasper_ 8y ago
Yes. The sandbox tool used by Flatpak is "bubblewrap", which has an overview here: https://github.com/projectatomic/bubblewrap/blob/master/README.md#user-namespaces https://github.com/projectatomic/bubblewrap/blob/master/READ... There is nothing against Flatpak using user namepsaces when the developers feel a bit more comfortable with that, though.
- lvh 8y ago
  Are you one of the developers/speaking for them? That warning is pretty old.
  - cyphar 8y ago
    Creation of user namespaces still has caused security vulnerabilities in very recent history. But with seccomp you can disable it inside a container (which is what Docker and LXC do by default for instance), and it doesn't make sense to be worried about that as a container runtime because you are using it to increase the security of your sandbox.
- cyphar 8y ago
  Bubblewrap supports user namespaces and has for a while -- grep through the source for CLONE_NEWUSER. I talk about the security concerns a bit in [1]. [1]: https://news.ycombinator.com/item?id=18181034 https://news.ycombinator.com/item?id=18181034
cyphar 8y ago
> docker uses user namespaces Docker has support for user namespaces but it's off by default, and I've never actually seen someone use them (I'm sure people do, but the way the support was implemented is fairly half-baked in a variety of ways, for a variety of understandable but still disappointing reasons). LXC/LXD's user namespace implementation actually privilege-separates different containers from each other (while also being able to "punch out" parts of the mapping so that you can share stuff between containers without needing to share the entire uid_map). > user namespaces requiring privileges to use Not always. See https://github.com/rootlesscontainers https://github.com/rootlesscontainers (a project I work on -- currently you can run Kubernetes as an unprivileged user with some caveats about multi-node setups but we're working on it) or LXC's unprivileged containers. And in cases where you need to have multi-user mappings (which isn't necessary for most user applications because they wouldn't be able to setuid anyway!) you can just use "newuidmap" and "newgidmap". In fact, bubblewrap has supported precisely this usecase and the use of user namespaces for a while. Of course, user namespaces wouldn't really help with protecting against home directory attacks -- if you're running as the same user (but in a user namespace) and you bind-mount the home directory then it can obviously write to said home directory.

by lvh 8y ago

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

Jasper_ 8y ago

Yes. The sandbox tool used by Flatpak is "bubblewrap", which has an overview here: https://github.com/projectatomic/bubblewrap/blob/master/README.md#user-namespaces https://github.com/projectatomic/bubblewrap/blob/master/READ... There is nothing against Flatpak using user namepsaces when the developers feel a bit more comfortable with that, though.

lvh 8y ago
Are you one of the developers/speaking for them? That warning is pretty old.
- cyphar 8y ago
  Creation of user namespaces still has caused security vulnerabilities in very recent history. But with seccomp you can disable it inside a container (which is what Docker and LXC do by default for instance), and it doesn't make sense to be worried about that as a container runtime because you are using it to increase the security of your sandbox.
cyphar 8y ago
Bubblewrap supports user namespaces and has for a while -- grep through the source for CLONE_NEWUSER. I talk about the security concerns a bit in [1]. [1]: https://news.ycombinator.com/item?id=18181034 https://news.ycombinator.com/item?id=18181034

cyphar 8y ago

> docker uses user namespaces Docker has support for user namespaces but it's off by default, and I've never actually seen someone use them (I'm sure people do, but the way the support was implemented is fairly half-baked in a variety of ways, for a variety of understandable but still disappointing reasons). LXC/LXD's user namespace implementation actually privilege-separates different containers from each other (while also being able to "punch out" parts of the mapping so that you can share stuff between containers without needing to share the entire uid_map). > user namespaces requiring privileges to use Not always. See https://github.com/rootlesscontainers https://github.com/rootlesscontainers (a project I work on -- currently you can run Kubernetes as an unprivileged user with some caveats about multi-node setups but we're working on it) or LXC's unprivileged containers. And in cases where you need to have multi-user mappings (which isn't necessary for most user applications because they wouldn't be able to setuid anyway!) you can just use "newuidmap" and "newgidmap". In fact, bubblewrap has supported precisely this usecase and the use of user namespaces for a while. Of course, user namespaces wouldn't really help with protecting against home directory attacks -- if you're running as the same user (but in a user namespace) and you bind-mount the home directory then it can obviously write to said home directory.