Isolated development environments to fend against bugs and malware in code under development, hygiene, etc.

[markstos]

One of the reasons to containerize data is to prevent malicious executable inside the container from getting access to my data. It appears that toolbox always mounts the host home directory in the container. That's convenient, but I would prefer if it was optional.

Not all containers need access to my SSH private key, keychain and other things that might be stored there.

[juhp]

You want a persistent user container without your /home? Just trying to understand the requirement/usecase better. - Say compared to just running a standard throwaway Fedora container?

[markstos]

Consider a Unix account which is used for both home and work. For a work container, I may prefer to mount only my work directory into the the container.

Consider an untrusted GUI app. It may only need access to a specific folder to load/save files. It doesn't need access to my .ssh folder and other unrelated files.

For improve security, Chrome OS does not share folders to containers by default from the host. There, if you want to provide data to the containers from your home directory or from a USB drive, you explicitly share it.

Containerization as a security feature loses significant value if you give the untrusted container all your data by default!

[markstos]

@juhp I see you work a good deal with Haskell packages. Presume that one of the Haskell packages you are install remotely has been compromised. Do Haskell packages need access to your .ssh folder or your Bitcoin wallet? Why share everything into your Haskell dev environment by default?

Fairly recently there was an NPM module that could still local Bitcoin if it was installed:
https://www.trendmicro.com/vinfo/nz/security/news/cybercrime-and-digital-threats/hacker-infects-node-js-package-to-steal-from-bitcoin-wallets

The module was popular and in fact my team had installed it into our tree. We didn't meet the the other criteria for it to trigger a bitcoin theft, but that risk would have been completely mitigated if our dev environment did not have complete access to our home directories by default. No employee would have chosen to share their Bitcoin wallet into this development environment.

[cgwalters]

This is totally valid but is going to be hard.

Practically speaking, I think the best path is to make it easy to run toolboxes as separate users (transiently create new uids, each with their own /home) - requires a privileged system service to do that.

[cgwalters]

Now if you want share some files e.g. read-only - that gets messier.

[juhp]

Is it possible to exclude files/dirs from a directory bind-mount?

[markstos]

To make sure I understand the challenge, I see that mounting the home directory happens in one line of code

    --volume "$HOME":"$HOME":rslave 

But the challenge here is still making GUI apps and some other features work, because those features expect that the user inside and outside the container is the same?

[oskarkook]

This is actually a rather important feature. I think it's fine to mount home by default, but it should be possible to use a container in an untrusted manner. Mounting home into a container assumes you trust the container, which in a throwaway container often isn't the case. Even in simple cases like testing some NPM module out, I'd like to have the peace of mind that it isn't going to wreck my home folder.

[juhp]

@markstos maybe you can test what you can do without the home mount or if just mounting a specific dir (cwd)?

[markstos]

@juhp Actually this was showstopper for me-- I stopped evaluating Silverblue once I ran into this missing feature. If this addressed, I may give Silverblue a second look. I was also disappointed to find that it wasn't easy to figure out how to run a Ubuntu container, which is the OS I've been using before.

If Fedora wants to welcome users coming from other Linux distros, making it easy to run their old distro in a container would be a good place to start.

[juhp]

@markstos thanks - I am just another Toolbox user. :-)
I agree completely that extending Toolbox to support more OSes would be very useful indeed.
Note that Toolbox also works without Silverblue (ie on other Fedora editions).

[cgwalters]

@juhp Actually this was showstopper for me-- I stopped evaluating Silverblue once I ran into this missing feature

What did you do before? Is there some other tool/approach you were using that didn't work on Silverblue?

Nothing at all stops you from e.g. using a disposable VM (QubesOS like), or for that matter having a custom script which implements some of the suggestions from this thread. Arguably, we should be more opinionated and build in QubesOS-like functionality into Silverblue.

But anyways existing VM and container technology is there. In fact toolbox today is really a bunch of scripts that make podman intentionally blur with the host. If you don't want the integration, you can start with podman run... since that's the default.

[markstos]

@cgwalters I have started using Chrome OS on my personal laptop and have come to appreciate the security of having my development environment (and nearly everything else) running within a container in VM through the Crostini project. I like that it supports GUI apps as well as command line apps. I also like that containers are private by default. I have to explicitly share data folders or USB drives with them. On the other hand, sound and wayland support is automatically set up in those containers.
url
I've been evaluating similar solutions to use on my work laptop instead. One option would be Neverware's Cloudready-- an open source Chrome OS for PC hardware. Sometimes there are ports that Crostini crashes, data is lost and starting over is necessary. For that reason, I hesitate on doubling down on ChromeOS / Crostini now.

Silverblue also looked compelling until I found it doesn't appear to support Ubuntu containers out of the box and it over-shares my personal data with containers I don't intend to trust. I also looked at Clear Linux. It has same concept of running nearly everything in containers. I am not thrilled with the close ties to Intel and x86. It's also not primarily a desktop OS. A final (default?) option would be to stick with Ubuntu as a desktop and move more my development work into LXD containers, which what Chrome's Crostini is using. I should be able copy LXD containers between my work and personal laptops even though the host OS is different. Using LXD templates, I should be able to set up a template shares enough mounts into the containers for Wayland support.

side note: Thanks for all the years of maintaining Rhythmbox!

[markstos]

Perhaps I misunderstand the mission of toolbox. From the README:

.. Intention of these systems is to discourage installation of software on the host

Why? With the default is to share all your personal data into the container by default, I don't think improved security can be claimed.

The remaining potential benefit would isolation, so you could install conflicting versions of software side-by-side.

If the always-share behavior remains, it could be helpful to update the docs clarify that the toolbox shares your entire home directory into the containers, that the behavior can't be disabled and it should not be used with untrusted containers.

I get that I can use podman directly, but I was interested a container solution with GUI integration. When searching on how to accomplish that with podman, using toolbox is the recommended approach:

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

[kronenpj]

@markstos If you're interested, I've created PR #298 which builds an Ubuntu 19.04 image.