10 ms·

Sandboxing all the things with Flatpak and BubbleBox

166 points by fanf2 3y ago

JeremyNT 3y ago
Bubblewrap is really a great sandboxing tool and I'm glad to see efforts to make it more "user friendly." One key thing to understand is that although it is used by Flatpak, you don't need to use Flatpak to use bubblewrap itself. The way I currently use bubblewrap is to write a small shell script with the correct invocation every time I want to sandbox something new. It isn't a great ux. The Arch wiki has documentation on how to do this [0]. I think probably because of its association with Flatpak there hasn't been a lot of work on improving the ux for "non-Flatpak" bubblewrap use cases, so I applaud the OP for their endeavors. I'm not sure I'll be switching from "just a bunch of shell scripts" for a third party tool like bubblebox (or the extant 3rd party GUI, bubblejail [1]), but it's a good idea to help improve the usability and open it up to more users. [0] https://wiki.archlinux.org/title/Bubblewrap https://wiki.archlinux.org/title/Bubblewrap [1] https://github.com/igo95862/bubblejail https://github.com/igo95862/bubblejail
racecar789 3y ago
Sandboxie works pretty well.
boustrophedon 3y ago
Since the author mentioned rewriting it in Rust, I recently added support to my library extrasafe that allows you to sandbox your own code: https://harrystern.net/extrasafe-user-namespaces.html https://harrystern.net/extrasafe-user-namespaces.html So if you wanted to call ffmpeg or some other C library with complicated user-provided data, you can use extrasafe's Isolates (along with its seccomp and Landlock features) to sandbox the call. I'm not really sure how suited it is for rewriting something like bubblewrap or firejail, but it might be interesting to try.
alhadrad 3y ago
https://news.ycombinator.com/item?id=29316024 https://news.ycombinator.com/item?id=29316024
fbdab103 3y ago
Cannot mention sandboxing flatpak without mentioning FlatSeal[0]. Offers a super convenient GUI to set per app configurations. [0] https://flathub.org/apps/com.github.tchx84.Flatseal https://flathub.org/apps/com.github.tchx84.Flatseal
- ralfj 3y ago
  Good point, I do indeed use Flatseal. I added it to the blog post.
- Timber-6539 3y ago
  Flatseal is awesome. Don't know if I would be using Flatpak's sandboxing feature (or even Flatpaks at all!) without it.
- troad 3y ago
  Isn't it just a thin wrapper around `flatpak permissions`? While obviously a handy GUI, I've never been able to overcome my trust issues with allowing a random package from GitHub to govern permissions for my Flatpaks. Ironically, I'd probably trust it a lot more if it came as a Debian package. There's a circular issue here where the people who are security conscious enough here to want something like Flatseal might also be too security conscious to install something like Flatseal.
  - duckmysick 3y ago
    If you're using KDE, they have a native permission manager: https://github.com/KDE/flatpak-kcm https://github.com/KDE/flatpak-kcm It's under System Settings -> Applications -> Flatpak Permission Settings
jamesponddotco 3y ago
If anyone want to look further into sandboxing applications on Linux, you can also look at AppArmor and the sandboxing features built into systemd. I love this repository for bases for AppArmor profiles[1], really good work. Never found a repository as good for systemd, but there are a few around. [1] https://github.com/roddhjav/apparmor.d https://github.com/roddhjav/apparmor.d
- darby_eight 3y ago
  Is there any indication Linux is going to adopt a pledge/unveil api in the near future? It's hard to place faith in systems like app armor that rely on system administrators to implement security guarantees.
  - boustrophedon 3y ago
    Linux has seccomp and landlock, which are basically harder-to-use versions of pledge/unveil.
    - PlutoIsAPlanet 3y ago
      Someone has combined those things to port Pledge to Linux. https://github.com/jart/pledge https://github.com/jart/pledge
  - DEADMINCE 3y ago
    I'd say that's a weird request as pledge/unveil are significantly less secure, even coming close to security theater IMO. Something like AppArmor can protect against a threat without having to rely on the developer to have done the right thing. Pledge/unveil would not help with the xz issue. AppArmor would.
    - darby_eight 3y ago
      > I'd say that's a weird request as pledge/unveil are significantly less secure, even coming close to security theater IMO. Compared to not using AppArmor, or compared to using AppArmor? The situation I'm concerned about is having an opt-in profile. (NB I don't understand how AppArmor works—linux security profiles are super confusing.)
ptx 3y ago
Why do the global overrides for Flatpak need "!~/.ssh" when they already have "!home"? Doesn't the latter deny access to the whole home directory? (If not, I would have expected many more entries in that deny list.)
- szundi 3y ago
  One change on home does not affect the ssh files. Probably failsafe for user error.
- timeflex 3y ago
  Good question... Flatpak seems !~/.ssh & !home as two different things... so !home will not block access to an app configured to access ~/.ssh.
codedokode 3y ago
It surprises me that Linux has no proper and detailed sandboxing out of the box. Are Linux users running untrusted closed-source applications and potentially backdoored open-source programs with full privileges? Maybe they should just post their root password online, it won't get worse anyway.
- cherryteastain 3y ago
  Linux is a kernel. Let alone sandboxing, it does not even have an init process or bootloader by default. You can install all the utilities expected of a modern desktop OS if you want, and most distros will do it for you.
- striking 3y ago
  Not every app needs to be run with "full privileges" (or "as root" as some might call it), but it does usually end up being a binary decision on most distros if you're not careful. Either it can change everything or it can only affect the entire user profile it's running under. Bwrap and friends allow you to do a lot of extra isolation and get much more granular, but non-root console-only apps are generally safe to run (and safer still to run under their own user instead of yours).
- yjftsjthsd-h 3y ago
  Linux has lots of sandboxing features. Many Linux distros only use them minimally because the value proposition is poor: Most distros don't ship closed-source applications and in the last 30 years there have only ever been a tiny number of backdoored open source packages. OTOH, sandboxing tends to break the kind of complex workflows that users are fond of. Another angle to point out is that some distros do bake in more protective features; consider Fedora using SELinux. Then, again, keep considering SELinux and observe how many things it breaks the moment you set a single foot off the trodden path.
  - mike_hearn 3y ago
    The Linux sandboxing features are mostly quite poor tbh. Compare to Apple's stack (if you include the private SBPL) and it doesn't come close. Apple is way ahead of both Windows and Linux when it comes to pervasive sandboxing.
Intralexical 3y ago
I kinda think having a tool to invoke `bwrap` is overkill for most cases. Applications I want to launch more than once just get a launcher script with `--bind "$(dirname "$(realpath "${BASH_SOURCE[0]}")")/FakeHome" ~` or other flags as appropriate. Same for tools that I don't want to install account-wide. Opening a terminal emulator in a `bwrap` sandbox and then using it to launch other applications and create new windows feels like using a VM, except it's all running natively. It's also quite useful to have aliases/functions in `.bashrc` for `--tmpfs ~` or `--bind "$(mktemp -d)" ~`, `--bind "$PWD" "$PWD"`, `--ro-bind "$PWD" "$PWD"`, etc., with varying levels of access to X11/DBus etc. You can quickly test how a code change behaves on a clean install, instantly see what configuration files something uses by running it in a clean sandbox and then running `tree`, and check on your first time using a new program that it isn't going to do anything crazy. I usually use some variant of `sandboxed-dir bash` or `sandboxed-rodir bash`, which I've `alias`ed to `bwrap` with flags as the names describe, whenever I'm about to either run `rm -rf` [1] or otherwise touch files which I'd rather not accidentally destroy. The BubbleWrap sandbox isn't useful just for security, but also for keeping configurations isolated/clean, and protecting against all manner of errors both in software and between the keyboard and chair. --- [1]: `echo rm -rvfi`, actually. See what you're doing before you run it for real, especially if there's a glob in there. And then the `bwrap --dev-bind / / --tmpfs ~ --bind "$PWD" "$PWD" bash` makes absolutely sure you're not going to do anything other than what you said you'd do.
- akdev1l 3y ago
  > I kinda think having a tool to invoke `bwrap` is overkill for most cases. It sounds like you built yourself some tooling that consists of miscellaneous shell scripts/functions/aliases.
  - 1oooqooq 3y ago
    a good engineer understands the value of not using something you never read the manual for. and how simple it feels after you did read the manual.
anthk 3y ago
Bwrap + microdistro = minichroot everywhere. That's how I run mosh under Hyperbola GNU/Linux.
- yjftsjthsd-h 3y ago
  Is microdistro a specific thing or a generic name for an approach? It doesn't obviously turn up in web search
  - anthk 3y ago
    Alpine for instance, but by taking care of not installing non-free stuff. I already run a libre kernel, so most of the stuff I installed it's fine, such as mosh and dependencies.
nextos 3y ago
I like bwrap, but I dislike Flatpak because it leads to obscure dependency management. AFAIK, in a scenario similar to the xz hack, it is hard to verify whether all apps are running compromised / patched versions of xz and dependencies. In contrast, regular package managers solve this problem pretty well. Therefore, I want bwrap or similar sandboxing + Nix / Guix.
- zer00eyz 3y ago
  >> In contrast, regular package managers solve this problem pretty well. Except the upstream dev's are sick of dealing with "It doesn't work in my distro" ... there are plenty of instances of these sorts of pissing matches. bwrap, flatpack, containers... were really talking about software distribution. I dont think any of these solutions "solve" the problem, we're just putting all the bullshit in one bag, not getting rid of it.
  - hx8 3y ago
    > Except the upstream dev's are sick of dealing with "It doesn't work in my distro" 99/100 it does work on their distro, they just need to handle their libraries better. Identify the packages they need to support the software, or if no packages exist then they need to compile the libraries themselves. The entire point of Linux distributions is to do this job for the user. Sometimes the distro will fall short, so you need to have the basic understanding to handle it yourself. Of course, Linux users aren't as tech savvy as they were 20 years ago.
    - akdev1l 3y ago
      > so you need to have the basic understanding to handle it yourself No they don’t. This idea that people need to become System Administrators to use Linux really needs to die.
      - nextos 3y ago
        You are bringing up a valid problem, but I think this needs to be fixed at UI level. There are GUIs getting developed for e.g. NixOS that lower the barrier to use the OS pretty dramatically. I agree things need to be simpler, but it would be nice to keep the capability to generate a bill of materials for each package. IMHO, Flatpak is a regression in some of these aspects.
deleted 3y ago
[deleted]
rustcleaner 3y ago
Just wanted to add, though obliquely relevant to the OP, I have daily driven Qubes OS 4.1 for at least 12 months now and have been thoroughly impressed. It actually makes me feel safe[r] in my online computing today. 8chan or Discord -delivered 0-day blowing up in one of the respective qubes should not lead to exfiltration of my Robinhood credentials, my aunt's baking recipes, or my super secret hacker darknet forum libressl key. :^) You want a beefy system. If you want to pass GPUs through, you need more than one in the system. CPU core count is important yes, but I cannot emphasize enough: RAM RAM RAM. Yes I do have automatic1111 running with GPU in my Qubes tower. Yes I can spin up a WinServ2022 Datacenter qube for Siemens NX 10, with full GPU support.
- fbdab103 3y ago
  I am this close to rebuilding my machine in Qubes. Is 32GB enough RAM or am I going to be seeing usability issues? The proliferation of AI tools really wants me to grab more of this wild-west code, but obvious security concerns there. Am I going to take a huge hit in performance if I am running this stuff in a virtual machine like llamafile which runs on the CPU? Secondary GPU for pass through is less appealing, but I suppose I can stomach it. Is there a good guide on how you configured this? Many moons ago, before Proton was so good, I had looked into doing GPU pass through, but quickly gave up on the technical complexity. Anything else notable? Problems getting web cams or microphones working? I assume you cannot screen share across Qubes.
  - damsalor 3y ago
    Screen sharing works across the planet nowadays
  - Dalewyn 3y ago
    >Secondary GPU for pass through is less appealing, but I suppose I can stomach it. Anyone using an Intel CPU from the past ~13 years or an AMD APU or Zen 4 CPU should have an iGPU to render the host with, unless they specifically opted out, leaving the GPU free for passthroughing.
  - fsflover 3y ago
its-summertime 3y ago
> filesystems=~/.XCompose:ro Doesn't ibus manage that for you? none of my programs have access to this file but I'm still able to use the changes I've made (as long as I restart ibus after changes)
- ralfj 3y ago
  shrug all I know is I fixed some issues with compose sequences by giving flatpak apps access to XCompose. It may be something with electron apps not properly using ibus?
timeflex 3y ago
I'm really frustrated with Flatpak. I thought it was going to be an exciting secure sandboxing solution, but found out the people running it just make terrible choices overall. Apps don't use their conventional names, so chromium ends up become org.chromium.Chromium & Visual Studio Code is com.visualstudio.code. They use fuse for mounts, which isn't necessary in modern Linux kernels that support nonroot overlays (think Podman). The whole point of sandboxing is to allow it to "hide" your real file system, and only mount what you need or permit access through D-Bus.. however, you'll find several apps that default to host access and access to all your /dev. They only provide a few device options as well... so, if you just want to give access to a webcam, well you have to provide all of /dev in most cases. Flatpak leaks all kinds of info about its sandbox too, so any app can easily determine its sandbox. If you want to setup custom mounts, for example to mount a specific host directory into a different sandbox directory, well you can't. It has to be a direct mapping from your host except it prevents you from mapping /etc/ directories. To work around this for sandboxed home directories, you can use a persistent directory mapping.. but now, you'll be trying to access your files in `~/.var/apps/org.chromium.Chromium/Downloads`. They also use a file forwarding concept, which doesn't work well when mixing arguments and files. For example, try using org.vim.Vim to pass arguments and open a file from the command line. Or, try editing system files with Flatpak where you need sudo or some privilege elevation. Why doesn't org.vim.Vim get aliased and work like regular vim? The typical solution suggested to fix anything is to add `org.freedesktop.Flatpak=talk` to the session bus, and use flatpak-spawn from within the sandbox. Many users do this not knowing the consequences. This is generally terrible advice as it will give any app in the sandbox complete host access. But what happens when you need access to host tools or native messaging apps from inside the Sandbox? Again, the top answers are to use flatpak-spawn. They have "SDK Extensions" for a few apps which are like binary dependencies, but many tools needed for things like Visual Studio Code just don't exist. Try using the Ansible extension in VS Code for example. Packaging them is a nightmare because they use a hodgepodge of tools/scripts inside a random GitHub repo to manually get all the Rust crates, node modules, python packages, etc. and add them to a nonstandard file inside your build manifest. It makes no sense why they never added this functionality to the builder itself. Development seems to be stalling. If you do build an app, good luck getting it on Flathub without some authoritarian mod telling you they don't like your app (see the Popcorn Time decision). Now, there are some good things. The build manifest is pretty neat. I like the idea of having a simple manifest to build apps that integrates with build tools, but the externals scripts it relies on makes it suck. Sandboxing isn't a unique concept. I can see an enthusiastic Rust/C/C++/Go/Typescript developer or developers doing the same thing 100x better. IMO sandboxed apps shouldn't even know they are sandboxed. Each app should have a clean environment and ideally you'd pick and choose what files/folders you want to give the app access to while it is running, and not let the app builder decide for you. Also, the user should pick and choose where to mount directories if they choose to do so.. not make ~/Documents mount to ~/Documents... what if I want to mount /mnt/dev/docs to ~/Documents. If you care about this stuff, then you may end up frustrated like me.
Arnavion 3y ago
I just use a Podman container to sandbox all the "closed-source / not from my distro's repo" software. https://news.ycombinator.com/item?id=34634584 https://news.ycombinator.com/item?id=34634584 Normally this is Ubuntu / Debian, but if I had TFA's specific problem of "I want the software to use my distro's /usr" I'd use a container with the base image of my distro. I don't bother sharing dbus, but if you did want to share (a subset of) it as TFA does, then yes xdg-dbus-proxy is a necessity.
chme 3y ago
I would love to see a Linux distribution picking up on the concept of NixOS, with its content-addressed-package store and then use overlayfs and bubblewrap to create process local FHS compatible root file systems with only the dependencies of each process inside.
- bjackman 3y ago
  They don't do the special package manager thing but aside from that I think the "immutable distros" like Fedora Silverblue are in this vein no?
  - chme 3y ago
    I would consider Fedora Silverblue/CoreOS, NixOS and even flatpak as a sort of hacky way to implement that. I don't know of any PoC for this. I would guess that there might be some research budget available for that approach.
- sham1 3y ago
  Well, both Guix System and NixOS can do this, where they construct a containerised environment with FHS layout. IIRC neither uses overlayfs and they do the namespaces by themselves instead of relying on Bubblewrap, but inside the container you get exactly what you'd expect. At least in Guix it's `guix shell -CF`, where `-C` is of course the `--container` flag, and `-F` for `--emulate-fhs`. I'd imagine that `nix-shell` works the same way, but I'm more familiar with guix than nix, so I can only speak for that.
  - chme 3y ago
    I only ever tried NixOS, but the FHS stuff there seems to only be about getting Steam and other proprietary software to work. I would suggest to have this per default, so that the only application that actually sees the real file system would be PID1.
    - sham1 3y ago
      That is an interesting idea, but I don't really see what the purpose would really be. As you said, having these kinds of FHS containers really is only actually useful for proprietary software, with free software being adaptable for a "non-standard" filesystem. Of course, it's sometimes helpful to do this even for free software, which is of course why this is an option, but I do struggle to see what would be the idea with making it the default for all non-PID1 apps in such a system. All I could really reckon is that it might be easier for user familiarity, but at least in my experience, one gets used to the new layout pretty quickly. You'd ideally be configuring the whole system in either Nix language or Scheme anyway, so things like `/etc` are a bit superfluous, and since you can get `/bin/sh` and `/usr/bin/env` symlinked for things that expect it, most things should work anyway. Well, unless done poorly, but nothing one couldn't patch.
slooonz 3y ago
Shameless self-plug : https://sloonz.github.io/posts/sandboxing-1/ https://sloonz.github.io/posts/sandboxing-1/ Which you can see it as the longer form documentation of bubblebox (explaining in excruciating details how to sandbox desktop applications with flatpak). (not affiliated to the author, written prior to bubblebox — but I’m happy to see that someone took up the job of making a true solution of implementing the ideas I laid out in my blog posts series !)
Hackbraten 3y ago
Currently unavailable, possibly due to hug of death. Archived version: https://archive.is/H5k0x https://archive.is/H5k0x

166 points by fanf2 3y ago

Bubblewrap is really a great sandboxing tool and I'm glad to see efforts to make it more "user friendly." One key thing to understand is that although it is used by Flatpak, you don't need to use Flatpak to use bubblewrap itself. The way I currently use bubblewrap is to write a small shell script with the correct invocation every time I want to sandbox something new. It isn't a great ux. The Arch wiki has documentation on how to do this [0]. I think probably because of its association with Flatpak there hasn't been a lot of work on improving the ux for "non-Flatpak" bubblewrap use cases, so I applaud the OP for their endeavors. I'm not sure I'll be switching from "just a bunch of shell scripts" for a third party tool like bubblebox (or the extant 3rd party GUI, bubblejail [1]), but it's a good idea to help improve the usability and open it up to more users. [0] https://wiki.archlinux.org/title/Bubblewrap https://wiki.archlinux.org/title/Bubblewrap [1] https://github.com/igo95862/bubblejail https://github.com/igo95862/bubblejail

racecar789 3y ago

Sandboxie works pretty well.

boustrophedon 3y ago

Since the author mentioned rewriting it in Rust, I recently added support to my library extrasafe that allows you to sandbox your own code: https://harrystern.net/extrasafe-user-namespaces.html https://harrystern.net/extrasafe-user-namespaces.html So if you wanted to call ffmpeg or some other C library with complicated user-provided data, you can use extrasafe's Isolates (along with its seccomp and Landlock features) to sandbox the call. I'm not really sure how suited it is for rewriting something like bubblewrap or firejail, but it might be interesting to try.

alhadrad 3y ago

https://news.ycombinator.com/item?id=29316024 https://news.ycombinator.com/item?id=29316024

fbdab103 3y ago

Cannot mention sandboxing flatpak without mentioning FlatSeal[0]. Offers a super convenient GUI to set per app configurations. [0] https://flathub.org/apps/com.github.tchx84.Flatseal https://flathub.org/apps/com.github.tchx84.Flatseal

ralfj 3y ago
Good point, I do indeed use Flatseal. I added it to the blog post.
Timber-6539 3y ago
Flatseal is awesome. Don't know if I would be using Flatpak's sandboxing feature (or even Flatpaks at all!) without it.
troad 3y ago
Isn't it just a thin wrapper around `flatpak permissions`? While obviously a handy GUI, I've never been able to overcome my trust issues with allowing a random package from GitHub to govern permissions for my Flatpaks. Ironically, I'd probably trust it a lot more if it came as a Debian package. There's a circular issue here where the people who are security conscious enough here to want something like Flatseal might also be too security conscious to install something like Flatseal.
- duckmysick 3y ago
  If you're using KDE, they have a native permission manager: https://github.com/KDE/flatpak-kcm https://github.com/KDE/flatpak-kcm It's under System Settings -> Applications -> Flatpak Permission Settings

jamesponddotco 3y ago

If anyone want to look further into sandboxing applications on Linux, you can also look at AppArmor and the sandboxing features built into systemd. I love this repository for bases for AppArmor profiles[1], really good work. Never found a repository as good for systemd, but there are a few around. [1] https://github.com/roddhjav/apparmor.d https://github.com/roddhjav/apparmor.d

darby_eight 3y ago
Is there any indication Linux is going to adopt a pledge/unveil api in the near future? It's hard to place faith in systems like app armor that rely on system administrators to implement security guarantees.
- boustrophedon 3y ago
  Linux has seccomp and landlock, which are basically harder-to-use versions of pledge/unveil.
  - PlutoIsAPlanet 3y ago
    Someone has combined those things to port Pledge to Linux. https://github.com/jart/pledge https://github.com/jart/pledge
- DEADMINCE 3y ago
  I'd say that's a weird request as pledge/unveil are significantly less secure, even coming close to security theater IMO. Something like AppArmor can protect against a threat without having to rely on the developer to have done the right thing. Pledge/unveil would not help with the xz issue. AppArmor would.
  - darby_eight 3y ago
    > I'd say that's a weird request as pledge/unveil are significantly less secure, even coming close to security theater IMO. Compared to not using AppArmor, or compared to using AppArmor? The situation I'm concerned about is having an opt-in profile. (NB I don't understand how AppArmor works—linux security profiles are super confusing.)

ptx 3y ago

Why do the global overrides for Flatpak need "!~/.ssh" when they already have "!home"? Doesn't the latter deny access to the whole home directory? (If not, I would have expected many more entries in that deny list.)

szundi 3y ago
One change on home does not affect the ssh files. Probably failsafe for user error.
timeflex 3y ago
Good question... Flatpak seems !~/.ssh & !home as two different things... so !home will not block access to an app configured to access ~/.ssh.

codedokode 3y ago

It surprises me that Linux has no proper and detailed sandboxing out of the box. Are Linux users running untrusted closed-source applications and potentially backdoored open-source programs with full privileges? Maybe they should just post their root password online, it won't get worse anyway.

cherryteastain 3y ago
Linux is a kernel. Let alone sandboxing, it does not even have an init process or bootloader by default. You can install all the utilities expected of a modern desktop OS if you want, and most distros will do it for you.
striking 3y ago
Not every app needs to be run with "full privileges" (or "as root" as some might call it), but it does usually end up being a binary decision on most distros if you're not careful. Either it can change everything or it can only affect the entire user profile it's running under. Bwrap and friends allow you to do a lot of extra isolation and get much more granular, but non-root console-only apps are generally safe to run (and safer still to run under their own user instead of yours).
yjftsjthsd-h 3y ago
Linux has lots of sandboxing features. Many Linux distros only use them minimally because the value proposition is poor: Most distros don't ship closed-source applications and in the last 30 years there have only ever been a tiny number of backdoored open source packages. OTOH, sandboxing tends to break the kind of complex workflows that users are fond of. Another angle to point out is that some distros do bake in more protective features; consider Fedora using SELinux. Then, again, keep considering SELinux and observe how many things it breaks the moment you set a single foot off the trodden path.
- mike_hearn 3y ago
  The Linux sandboxing features are mostly quite poor tbh. Compare to Apple's stack (if you include the private SBPL) and it doesn't come close. Apple is way ahead of both Windows and Linux when it comes to pervasive sandboxing.

Intralexical 3y ago

I kinda think having a tool to invoke `bwrap` is overkill for most cases. Applications I want to launch more than once just get a launcher script with `--bind "$(dirname "$(realpath "${BASH_SOURCE[0]}")")/FakeHome" ~` or other flags as appropriate. Same for tools that I don't want to install account-wide. Opening a terminal emulator in a `bwrap` sandbox and then using it to launch other applications and create new windows feels like using a VM, except it's all running natively. It's also quite useful to have aliases/functions in `.bashrc` for `--tmpfs ~` or `--bind "$(mktemp -d)" ~`, `--bind "$PWD" "$PWD"`, `--ro-bind "$PWD" "$PWD"`, etc., with varying levels of access to X11/DBus etc. You can quickly test how a code change behaves on a clean install, instantly see what configuration files something uses by running it in a clean sandbox and then running `tree`, and check on your first time using a new program that it isn't going to do anything crazy. I usually use some variant of `sandboxed-dir bash` or `sandboxed-rodir bash`, which I've `alias`ed to `bwrap` with flags as the names describe, whenever I'm about to either run `rm -rf` [1] or otherwise touch files which I'd rather not accidentally destroy. The BubbleWrap sandbox isn't useful just for security, but also for keeping configurations isolated/clean, and protecting against all manner of errors both in software and between the keyboard and chair. --- [1]: `echo rm -rvfi`, actually. See what you're doing before you run it for real, especially if there's a glob in there. And then the `bwrap --dev-bind / / --tmpfs ~ --bind "$PWD" "$PWD" bash` makes absolutely sure you're not going to do anything other than what you said you'd do.

akdev1l 3y ago
> I kinda think having a tool to invoke `bwrap` is overkill for most cases. It sounds like you built yourself some tooling that consists of miscellaneous shell scripts/functions/aliases.
- 1oooqooq 3y ago
  a good engineer understands the value of not using something you never read the manual for. and how simple it feels after you did read the manual.

anthk 3y ago

Bwrap + microdistro = minichroot everywhere. That's how I run mosh under Hyperbola GNU/Linux.

yjftsjthsd-h 3y ago
Is microdistro a specific thing or a generic name for an approach? It doesn't obviously turn up in web search
- anthk 3y ago
  Alpine for instance, but by taking care of not installing non-free stuff. I already run a libre kernel, so most of the stuff I installed it's fine, such as mosh and dependencies.

nextos 3y ago

I like bwrap, but I dislike Flatpak because it leads to obscure dependency management. AFAIK, in a scenario similar to the xz hack, it is hard to verify whether all apps are running compromised / patched versions of xz and dependencies. In contrast, regular package managers solve this problem pretty well. Therefore, I want bwrap or similar sandboxing + Nix / Guix.

zer00eyz 3y ago
>> In contrast, regular package managers solve this problem pretty well. Except the upstream dev's are sick of dealing with "It doesn't work in my distro" ... there are plenty of instances of these sorts of pissing matches. bwrap, flatpack, containers... were really talking about software distribution. I dont think any of these solutions "solve" the problem, we're just putting all the bullshit in one bag, not getting rid of it.
- hx8 3y ago
  > Except the upstream dev's are sick of dealing with "It doesn't work in my distro" 99/100 it does work on their distro, they just need to handle their libraries better. Identify the packages they need to support the software, or if no packages exist then they need to compile the libraries themselves. The entire point of Linux distributions is to do this job for the user. Sometimes the distro will fall short, so you need to have the basic understanding to handle it yourself. Of course, Linux users aren't as tech savvy as they were 20 years ago.
  - akdev1l 3y ago
    > so you need to have the basic understanding to handle it yourself No they don’t. This idea that people need to become System Administrators to use Linux really needs to die.
    - nextos 3y ago
      You are bringing up a valid problem, but I think this needs to be fixed at UI level. There are GUIs getting developed for e.g. NixOS that lower the barrier to use the OS pretty dramatically. I agree things need to be simpler, but it would be nice to keep the capability to generate a bill of materials for each package. IMHO, Flatpak is a regression in some of these aspects.

deleted 3y ago

[deleted]

rustcleaner 3y ago

Just wanted to add, though obliquely relevant to the OP, I have daily driven Qubes OS 4.1 for at least 12 months now and have been thoroughly impressed. It actually makes me feel safe[r] in my online computing today. 8chan or Discord -delivered 0-day blowing up in one of the respective qubes should not lead to exfiltration of my Robinhood credentials, my aunt's baking recipes, or my super secret hacker darknet forum libressl key. :^) You want a beefy system. If you want to pass GPUs through, you need more than one in the system. CPU core count is important yes, but I cannot emphasize enough: RAM RAM RAM. Yes I do have automatic1111 running with GPU in my Qubes tower. Yes I can spin up a WinServ2022 Datacenter qube for Siemens NX 10, with full GPU support.

fbdab103 3y ago
I am this close to rebuilding my machine in Qubes. Is 32GB enough RAM or am I going to be seeing usability issues? The proliferation of AI tools really wants me to grab more of this wild-west code, but obvious security concerns there. Am I going to take a huge hit in performance if I am running this stuff in a virtual machine like llamafile which runs on the CPU? Secondary GPU for pass through is less appealing, but I suppose I can stomach it. Is there a good guide on how you configured this? Many moons ago, before Proton was so good, I had looked into doing GPU pass through, but quickly gave up on the technical complexity. Anything else notable? Problems getting web cams or microphones working? I assume you cannot screen share across Qubes.
- damsalor 3y ago
  Screen sharing works across the planet nowadays
- Dalewyn 3y ago
  >Secondary GPU for pass through is less appealing, but I suppose I can stomach it. Anyone using an Intel CPU from the past ~13 years or an AMD APU or Zen 4 CPU should have an iGPU to render the host with, unless they specifically opted out, leaving the GPU free for passthroughing.
- fsflover 3y ago

its-summertime 3y ago

> filesystems=~/.XCompose:ro Doesn't ibus manage that for you? none of my programs have access to this file but I'm still able to use the changes I've made (as long as I restart ibus after changes)

ralfj 3y ago
shrug all I know is I fixed some issues with compose sequences by giving flatpak apps access to XCompose. It may be something with electron apps not properly using ibus?

timeflex 3y ago

I'm really frustrated with Flatpak. I thought it was going to be an exciting secure sandboxing solution, but found out the people running it just make terrible choices overall. Apps don't use their conventional names, so chromium ends up become org.chromium.Chromium & Visual Studio Code is com.visualstudio.code. They use fuse for mounts, which isn't necessary in modern Linux kernels that support nonroot overlays (think Podman). The whole point of sandboxing is to allow it to "hide" your real file system, and only mount what you need or permit access through D-Bus.. however, you'll find several apps that default to host access and access to all your /dev. They only provide a few device options as well... so, if you just want to give access to a webcam, well you have to provide all of /dev in most cases. Flatpak leaks all kinds of info about its sandbox too, so any app can easily determine its sandbox. If you want to setup custom mounts, for example to mount a specific host directory into a different sandbox directory, well you can't. It has to be a direct mapping from your host except it prevents you from mapping /etc/ directories. To work around this for sandboxed home directories, you can use a persistent directory mapping.. but now, you'll be trying to access your files in `~/.var/apps/org.chromium.Chromium/Downloads`. They also use a file forwarding concept, which doesn't work well when mixing arguments and files. For example, try using org.vim.Vim to pass arguments and open a file from the command line. Or, try editing system files with Flatpak where you need sudo or some privilege elevation. Why doesn't org.vim.Vim get aliased and work like regular vim? The typical solution suggested to fix anything is to add `org.freedesktop.Flatpak=talk` to the session bus, and use flatpak-spawn from within the sandbox. Many users do this not knowing the consequences. This is generally terrible advice as it will give any app in the sandbox complete host access. But what happens when you need access to host tools or native messaging apps from inside the Sandbox? Again, the top answers are to use flatpak-spawn. They have "SDK Extensions" for a few apps which are like binary dependencies, but many tools needed for things like Visual Studio Code just don't exist. Try using the Ansible extension in VS Code for example. Packaging them is a nightmare because they use a hodgepodge of tools/scripts inside a random GitHub repo to manually get all the Rust crates, node modules, python packages, etc. and add them to a nonstandard file inside your build manifest. It makes no sense why they never added this functionality to the builder itself. Development seems to be stalling. If you do build an app, good luck getting it on Flathub without some authoritarian mod telling you they don't like your app (see the Popcorn Time decision). Now, there are some good things. The build manifest is pretty neat. I like the idea of having a simple manifest to build apps that integrates with build tools, but the externals scripts it relies on makes it suck. Sandboxing isn't a unique concept. I can see an enthusiastic Rust/C/C++/Go/Typescript developer or developers doing the same thing 100x better. IMO sandboxed apps shouldn't even know they are sandboxed. Each app should have a clean environment and ideally you'd pick and choose what files/folders you want to give the app access to while it is running, and not let the app builder decide for you. Also, the user should pick and choose where to mount directories if they choose to do so.. not make ~/Documents mount to ~/Documents... what if I want to mount /mnt/dev/docs to ~/Documents. If you care about this stuff, then you may end up frustrated like me.

Arnavion 3y ago

I just use a Podman container to sandbox all the "closed-source / not from my distro's repo" software. https://news.ycombinator.com/item?id=34634584 https://news.ycombinator.com/item?id=34634584 Normally this is Ubuntu / Debian, but if I had TFA's specific problem of "I want the software to use my distro's /usr" I'd use a container with the base image of my distro. I don't bother sharing dbus, but if you did want to share (a subset of) it as TFA does, then yes xdg-dbus-proxy is a necessity.

chme 3y ago

I would love to see a Linux distribution picking up on the concept of NixOS, with its content-addressed-package store and then use overlayfs and bubblewrap to create process local FHS compatible root file systems with only the dependencies of each process inside.

bjackman 3y ago
They don't do the special package manager thing but aside from that I think the "immutable distros" like Fedora Silverblue are in this vein no?
- chme 3y ago
  I would consider Fedora Silverblue/CoreOS, NixOS and even flatpak as a sort of hacky way to implement that. I don't know of any PoC for this. I would guess that there might be some research budget available for that approach.
sham1 3y ago
Well, both Guix System and NixOS can do this, where they construct a containerised environment with FHS layout. IIRC neither uses overlayfs and they do the namespaces by themselves instead of relying on Bubblewrap, but inside the container you get exactly what you'd expect. At least in Guix it's `guix shell -CF`, where `-C` is of course the `--container` flag, and `-F` for `--emulate-fhs`. I'd imagine that `nix-shell` works the same way, but I'm more familiar with guix than nix, so I can only speak for that.
- chme 3y ago
  I only ever tried NixOS, but the FHS stuff there seems to only be about getting Steam and other proprietary software to work. I would suggest to have this per default, so that the only application that actually sees the real file system would be PID1.
  - sham1 3y ago
    That is an interesting idea, but I don't really see what the purpose would really be. As you said, having these kinds of FHS containers really is only actually useful for proprietary software, with free software being adaptable for a "non-standard" filesystem. Of course, it's sometimes helpful to do this even for free software, which is of course why this is an option, but I do struggle to see what would be the idea with making it the default for all non-PID1 apps in such a system. All I could really reckon is that it might be easier for user familiarity, but at least in my experience, one gets used to the new layout pretty quickly. You'd ideally be configuring the whole system in either Nix language or Scheme anyway, so things like `/etc` are a bit superfluous, and since you can get `/bin/sh` and `/usr/bin/env` symlinked for things that expect it, most things should work anyway. Well, unless done poorly, but nothing one couldn't patch.

slooonz 3y ago

Shameless self-plug : https://sloonz.github.io/posts/sandboxing-1/ https://sloonz.github.io/posts/sandboxing-1/ Which you can see it as the longer form documentation of bubblebox (explaining in excruciating details how to sandbox desktop applications with flatpak). (not affiliated to the author, written prior to bubblebox — but I’m happy to see that someone took up the job of making a true solution of implementing the ideas I laid out in my blog posts series !)

Hackbraten 3y ago

Currently unavailable, possibly due to hug of death. Archived version: https://archive.is/H5k0x https://archive.is/H5k0x