[HN Gopher] Sandboxing all the things with Flatpak and BubbleBox
___________________________________________________________________
Sandboxing all the things with Flatpak and BubbleBox
Author : fanf2
Score : 59 points
Date : 2024-04-14 19:04 UTC (3 hours ago)
(HTM) web link (www.ralfj.de)
(TXT) w3m dump (www.ralfj.de)
| boustrophedon wrote:
| 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
|
| 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 wrote:
| https://news.ycombinator.com/item?id=29316024
| fbdab103 wrote:
| 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
| jamesponddotco wrote:
| 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
| ptx wrote:
| 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 wrote:
| One change on home does not affect the ssh files. Probably
| failsafe for user error.
| codedokode wrote:
| 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 wrote:
| 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.
| Intralexical wrote:
| 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.
| anthk wrote:
| Bwrap + microdistro = minichroot everywhere. That's how I run
| mosh under Hyperbola GNU/Linux.
| nextos wrote:
| 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 wrote:
| >> 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.
___________________________________________________________________
(page generated 2024-04-14 23:00 UTC)