Stéphane Graber

The link in the parent post is probably the best source, particularly the line: > While the team behind Linux Containers regrets that decision and will be missing LXD as one of its projects, it does respect Canonical’s decision That team includes Stéphane Graber who was for years the project lead for LXD, and a highly-visible evangelist for the project, producing videos[1] every couple weeks and answering questions on the forum[2]. He quit Canonical a few days after this announcement[3]. [1]: https://www.youtube.com/@LXD/videos [2]: https://discuss.linuxcontainers.org [3]: https://stgraber.org/2023/07/10/time-to-move-on/

For sure. Interestingly, it looks like Stephane gave his resignation first: > Following the announcement of my resignation, Canonical decided to pull LXD out of the Linux Containers projects and relocate it to a full in-house project [1]. 1. https://stgraber.org/2023/07/10/time-to-move-on/

Can someone talk about LXC security in practice? I've read[1], and it is excellent to have options, but there I'd like guidance for what is actually usable and useful, especially via Docker. Background: I want to be able to execute arbitrary code submitted from the web. At the moment I'm sandboxing it inside a ZeroVM[2] container, inside a Docker (LXC) container. I'd like to lock down the Docker container more than the default (eg, disable outgoing network connections), but I don't really know where to start. (And yes, I do find it strange that it was easier to get an entirely new, experimental and undocumented container running inside LXC than it was to work out how to configure LXC. But layers are good, right?) [1] https://www.stgraber.org/2014/01/01/lxc-1-0-security-features/ [2] http://zerovm.org/

I've also struggled with the distinction, but I believe the commenter above was referring to LXC (and LXD's) "system containers". Full user namespacing has been in from very early on (day 1?) which is the "increased security" -- this is where I believed the difference between "system containers" for LXC and regular "application containers" was. runc was not always the runtime underneath Docker, and IIRC it has not always had support for proper user namespacing for as long as LXC has. Also, LXC has so many more features packed in I think it's a disservice to compare it to runc in the first place. It should go without saying but I would absolutely love for you to sprinkle some knowledge on me wherever I'm wrong about either of these. [EDIT] - Getting downvotes so figured maybe I said something egregious so I did some digging: - LXC had user namespaces @ v1.0 in 2013[0] - Docker got user namespaces @ 1.10 in 2016[1] This is the distinction I meant. [0]: https://stgraber.org/2014/01/01/lxc-1-0-security-features/ [1]: https://blog.docker.com/2016/02/docker-1-10/

And upstream doesn't have significant intentions for dendrite right now... Relevant btw re: licensing: https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-under-a-cla/

He answered that in a comment: https://stgraber.org/2023/08/24/stable-linux-mainline-builds/#comment-…

Canonical cannot do that. https://stgraber.org/2023/07/10/time-to-move-on/

The likely reason behind this, given today’s news, is https://stgraber.org/2023/07/10/time-to-move-on/

I think that essentially, the LXD project focuses on making VM-like containers (with a full OS that you SSH into, etc), whereas Docker and friends focus on immutable application containers - essentially, a zone for running a single application, and which you delete and start from scratch rather than entering and changing stuff. In fact, the LXD people have a guide on how to run Docker containers inside LXD :) https://stgraber.org/2016/04/13/lxd-2-0-docker-in-lxd-712/

If you use LXD in Ubuntu, you can (and should) have your containers stored in the ZFS filesystem. I have be doing that, and did not notice any problems. About LXD: https://stgraber.org/2016/03/11/lxd-2-0-blog-post-series-012/

You can create either privileged or unprivileged LXC containers. Creating Unprivileged containers only requires a very simple configuration that takes 60 seconds to do. Here's Stephane Graber's blog on it: https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/ Also, note that with LXD/LXC the "default" container is now unprivileged. Also with LXD/LXC the LXC command syntax is now simplified even more than it was with traditional LXC but with the added power of being able to orchestrate and manage LXC containers either remotely or locally. https://linuxcontainers.org/lxd/getting-started-cli/

I think he meant LXD, the daemon for managing LXC containers written by Canonical. See https://www.stgraber.org/2015/04/21/lxd-getting-started/. I guess that the point is that, compared to other solutions, Docker was specifically meant to run with only one service per container instance.

"Working with silicon companies to ensure hardware-assisted security" doesn't mean that much though. A MMU is already hardware-assisted security. https://linuxcontainers.org/lxd/introduction/ says "unprivileged containers" as the leading security feature. Googling for that, there's more info at https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/

You can also use just LXC to do the same: https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/

This is actually quite similar to using LXC containers to run GUI apps. Something like Wine would be a good candidate to run in a container, perhaps others too. And you can use both privileged and unprivileged containers for this. I have a guide on running accelerated GUI apps in both privileged and unprivileged containers: http://www.flockport.com/run-gui-apps-in-lxc-containers and here's one more by Stephane Graber, lead developer of LXC using only unprivileged containers: https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/

My understanding is that recent (13.10+) Ubuntu ships with an AppArmor profile that blocks known ways of escalating out of the container. So, LXC under Ubuntu is in better shape than LXC on other distros, where you can use the uevent_helper trick[1] to easily escape the container. It sounds like your use case could also use the new unprivileged containers[2] feature, which is going to be a dramatic increase in security (since even if you somehow get access to run a command on the host container, it would not be as root). [1]: http://blog.bofh.it/debian/id_413 [2]: https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/

> performance hit Should be negligible. > compare to *bsd jails Similar in many respects. > primer on security Still a little sketchy, but see: https://www.stgraber.org/2014/01/01/lxc-1-0-security-features/ http://www.slideshare.net/jpetazzo/linux-containers-lxc-docker-and-sec… LXC uses the same kernel for all containers, so containers/hosts will always be vulnerable to buggy syscalls.

Thanks, must've missed that! Apparently caching isn't enabled though[1]. [1]: http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/

You can approximate this right now with LXC[1]. Ubuntu has really good support for it[2], but any recent kernel will be able to do what you need. Basically, you install linux on a VM or a real hardware machine, then you use LXC to partition off individual processes into their own little linux VM. These VMs can be severely limited in scope, even going so far as to be ephemeral (any disk writes go away at VM stop time). [1]: http://lxc.sourceforge.net/ [2]: http://www.stgraber.org/2012/05/04/lxc-in-ubuntu-12-04-lts/

> https://github.com/zabbly/incus/issues/89#issuecomment-30764... > I mean sure, it's the UI component only, and not on the lxc repo but the Zabbly one, and maybe they treat things widely differently depending. This one is fair since Incus and Zabbly have had no desire to reimplement a web UI, they've instead opted to leave that to the community resulting in LXConsole for example. Zabbly, for additional context, is Stephane Graber's company that he set up as a consultant service for Linux and Linux Container (both in terms of the Linux Container organization and the LXC project) As a whole, the project has left the choice of web interface up to the user: https://discuss.linuxcontainers.org/t/incus-6-7-has-been-released/2209… > But it's the same developer for both, and I'm willing to bet it's a similar mindset for projects. This is getting dangerously close to a mischaracterization of events surrounding the Linux Containers and Canonical split. See: https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-under-a-cla/ in addition to: https://linuxcontainers.org/incus/announcement/ EDIT: I read this part to suggest that former LXD team members that are now on the Incus team potentially have the same mindset, if this is wrong, please correct me. > And I swear I had a similar experience with regards to some other incus issues where there was a similar response about changes. So far from my two years of interaction (both as a lurker and commenter) on the forums and…

> my understanding is that if you sign a CLA, you typically give a right to relicence to the beneficiary of the CLA. Just to clarify, this depends upon the exact CLA you sign. Canonical's CLA (CCLA) [1] for example, contains this clause in Section 2.3 Outbound license: > We may license the Contribution under any licence, including copyleft, permissive, commercial, or proprietary licences. As a condition on the exercise of this right, We agree to also license the Contribution under the terms of the licence or licences which We are using for the Material on the Submission Date. This means that they promise to release your contribution under the original license as well. Or in other words, they won't relicense the old contributions retroactively. There may be other CLAs that don't make this promise. It's generally a good idea to read and understand what you are signing up for. (Applicable for any agreements, not just CLAs, since your argument is to avoid them.) Almost all CLAs let the contributor retain the copyright. (If I understand correctly, copyright transfers are involved only in CAAs.) So that option is also available for you to do whatever you want to do with your contributions. In any case, the actual problem is the breach of an unwritten trust you place in the project owners. Since you generously contributed your work to them and everyone else, you'd expect the same favor in return for the contributions by others in the future. But CLAs leave that open and under…