Investigate bubblewrap for sandboxing

[probonopd]

https://github.com/projectatomic/bubblewrap

To run an AppImage in a read-only sandbox so that it can only write to $HOME/.config/leafpad/ and $HOME/leafpad/:

# Get the sandbox
wget -c "https://github.com/probonopd/bubblewrap/releases/download/binary/bwrap"
# Get the AppImage to be run inside the sandbox
wget -c "https://bintray.com/probono/AppImages/download_file?file_path=Leafpad-0.8.17-x86_64.AppImage" -O Leafpad-0.8.17-x86_64.AppImage
# FUSE-mounting does not seem to work inside the sandbox
sudo mount Leafpad-0.8.17-x86_64.AppImage /mnt -o loop
chmod a+x ./bwrap
mkdir -p $HOME/leafpad/
mkdir -p $HOME/.config/leafpad/
./bwrap --ro-bind / / --dev /dev --bind  $HOME/.config/leafpad/ $HOME/.config/leafpad/ --bind  $HOME/leafpad/ $HOME/leafpad/ /mnt/AppRun
sudo umount /mnt

Works for me :-)

[hideout]

works for me too!
thanks

2016-06-03 17:28 GMT+02:00 probonopd notifications@github.com:

To run an AppImage in a read-only sandbox:

sudo mount some.AppImage /mnt -o loop
bwrap --ro-bind / / /mnt/AppRun
sudo umount /mnt

Works for me :-)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#152, or mute the thread
https://github.com/notifications/unsubscribe/AAjGjQ4n4HwWv1VcbG7ieTWkxwKXzSbZks5qIEgwgaJpZM4ItpPh
.

[probonopd]

See https://github.com/probonopd/AppImageKit/tree/master/sandbox

[probonopd]

Let's see if three years later we can get this to work without needing root rights for mounting the AppImage.

wget https://transfer.sh/Ngoi2/bwrap
chmod +x bwrap

./GoTranslate-12-x86_64.AppImage --appimage-offset
188392

# Looks like we would need a small helper tool that would need to run as root (or polkit org.freedesktop.udisks2.filesystem-mount?) to mount the AppImage using the kernel
sudo mount /isodevice/Applications/GoTranslate-12-x86_64.AppImage /mnt -o loop,offset=188392

# Bubblewrap can then run the AppImage just fine, without needing any extra permissions on Ubuntu 18.04.2
./bwrap --ro-bind / / --dev /dev /mnt/AppRun

Now, does Firejail also have the same fine-grained, easy controls to run applications e.g., without network access, with their own temporary r/w filesystem that gets discarded when the application quits, etc.? What woud be the upsides and downsides of using it vs. Bubblewrap?

[probonopd]

The org.freedesktop.udisks2.filesystem-mount route for mounting disks doesn't let us set the mountpoint, meaning that AppImages would get mounted like normal disks, which might be annoying. Hence we should mount them like snapd does, which unfortunately seems tor requie the installation of custom polkit rules (to be verified).

Firejail easily gets around all of this because it is run as setuid root.

[TheAssassin]

Why do you need to mount anything as loop device? You can mount your AppImage via FUSE, can't you?

[probonopd]

Not when using Bubblewrap. Or so I believe (so far). But before I continue spending time with Bubblewrap I'd actually like to know its pros and cons vs. Firejail, which has the big plus of active AppImage support.

[mgord9518]

IMO, I have nothing against FireJail, but I can think of at least 2 major advantages of bubblewrap right off the bat:

1. Easier interface
2. Pre-installed on any system that comes with Flatpak, which is quite common nowadays.

Along with FireJail not appearing to run AppImages correctly, even with the '--appimage' option, it failed to work with every Electron app I've tested, doesn't work with the RuneLite AppImage, and the LibreWolf AppImage is unable to utilize the Firefox profile, but that one may be a combination of issues. Regardless, it was frustrating enough to make me, who is pretty persistent about this kind of stuff, completely give up on using it with AppImages.

However, I was able to get bubblewrap working with AppImages mounted via FUSE with a (pretty hacky) script that just utilizes the AppImage runtime. It's my personal script that I've been (mostly successful) running my AppImages, but hopefully other people who had the same issues will find it of use.

I've been considering making some sort of modified version of the runtime that doesn't require ^C to unmount, but I don't know C worth jack :/ also even that seems like a patch job. I had tried using squashfuse which I feel like would be the best option, but it doesn't appear to have an offset option, so I was unable to mount the AppImages.

#!/usr/bin/env bash

# The sandboxing done here is nowhere near maximum, its main use is
# to keep applications from accessing your entire $HOME and some device
# files without permission, DO NOT use it to run sketchy stuff

# Also WIP

[ ! $(which ./runtime) ]  && echo "FATAL: AppImage runtime not found in script directory"

RUNID=$RANDOM$RANDOM

# Variables
TMPDIR="/tmp/.appimage_sb.$RUNID"  # Where the AppImage will be mounted
ROOTDIR="/"                        # The root directory for the filesystem you want to use
                                   # Use "/" for your real filesystem, or create a virtual
                                   # filesystem of another distro, similar in to a chroot

TARGET_APPIMAGE="$1"
DATADIR="${TARGET_APPIMAGE}.home"  # Where to store the data for target AppImage

mkdir -p $DATADIR/ \
         $TMPDIR/

# Mount the AppImage using an external AppImage runtime (in case the 
# AppImage we want to sandbox is malicious)
(TMPDIR=$TMPDIR TARGET_APPIMAGE=$1 ./runtime --appimage-mount) &
PID=$!

# Give the runtime time to mount the appimage
sleep 0.05

# Sandbox using bubblewrap
# This worked for SuperTuxKart, RuneLite, Libre Wolf browser, GIMP and others.
# I'm still learning what all this means though, honestly I just fiddled with it until
# everything worked with what appears to be relatively isolated, at least home-wise.
bwrap --unshare-uts \
--hostname restricted \
--unshare-pid \
--ro-bind $ROOTDIR/bin/ /bin/ \
--ro-bind $ROOTDIR/usr/ /usr/ \
--ro-bind $ROOTDIR/lib/ /lib/ \
--ro-bind-try $ROOTDIR/lib64/ /lib64/ \
--ro-bind-try $ROOTDIR/lib32/ /lib32/ \
--ro-bind $ROOTDIR/bin/ /bin/ \
--ro-bind $ROOTDIR/sbin/ /sbin/ \
--ro-bind $ROOTDIR/etc/ /etc/ \
--dev /dev/ \
--dev-bind /dev/dri /dev/dri \
--dev-bind /dev/input /dev/input \
--proc /proc/ \
--bind /run/ /run/ \
--bind $ROOTDIR/var/ /var/ \
--bind /sys/ /sys/ \
--dir /home/ \
--bind $DATADIR/ $HOME \
--bind $HOME/Downloads/ $HOME/Downloads/ \
--ro-bind $TMPDIR/.mount*/ $HOME/.AppImage/ \
--tmpfs tmp/ \
/bin/sh -c $HOME/.AppImage/AppRun

# Unmount the AppImage and filesystem
kill $PID

# Give everything time to unmount
sleep 0.5

# Remove the temporary directories
rm -r $TMPDIR 

I have tested this script on Manjaro and PopOS, but I'm not at all sure what else it'll work on.

PS: If bubblewrap says it fails to find "source path /tmp/.appimage_sb./.mount_", try extending the sleep time under "# Give the runtime time to mount the AppImage"

[probonopd]

Thanks @mgord9518

[probonopd]

Possibly of interest:
https://github.com/igo95862/bubblejail

Bubblejail is a bubblewrap-based alternative to Firejail.

A developer of Alpine Linux says:

We removed firejail because it has an atrocious security record, and the idea of a SUID program being used to provide improved security is fundamentally flawed. It will not be readded.
(...)
Some alternatives to consider in edge include bubblejail, using bwrap directly or using unshare. All of which achieve the same behavior as firejail, but without being SUID.

https://gitlab.alpinelinux.org/alpine/aports/-/issues/12643

I don't want to judge the security record of anything, but I can follow the logic that SUID should be avoided if similar/the same effects can be achieved without needing it.

[mundusnine]

I would really weight the advantages of using bubblejail vs bubblewrap. bubblejail is just some python scripts which add a python dep. Personally, as I am making an appimage installer and wanting to have as minimal deps as possible a python dep is too much compared to just having bubblewrap's binary be dropped in and calling that directly.

Just my 2 cents.

[probonopd]

No worries, the user decides whether to use a sandbox and which one. AppImage does not require one. I will not be doing work in this area.

[mgord9518]

How do you feel about having a standardized way for AppImages to request permissions from a sandboxing program? (in the form of a wrapper from an optional launcher/daemon).

At least directories and files would be super easy to implement for any sandboxes, the more fidgety settings like which devices to restrict will be trickier.

Regardless, just sandboxing files is a lot better than not sandboxing at all.

Example (web browser?):

[Desktop Entry]
...
X-AppImage-FS-Needed=~/Downloads:rw;
X-AppImage-FS-Suggested=~/Documents:ro;~/Pictures:rw;

[TheAssassin]

TheAssassin/AppImageLauncher#99

[mgord9518]

So what I'm getting out of this is... everyone is on the same page here, it just currently hasn't been implemented yet?

I can start working on a basic tool to read minimal permissions and expand from there to make it more secure.

[probonopd]

How do you feel about having a standardized way for AppImages to request permissions from a sandboxing program?

I'm happy with the idea as long as sandboxing is opt-in, and as long as the requested permissions are conceptually abstract enough so that they can work with different underlying sandboxes.

I can start working on a basic tool to read minimal permissions and expand from there to make it more secure.

First step would be to brainstorm about the different permissions. Maybe it would be useful to look into the XDG Portals as well. (I know nothing about them, really.)

But the whole sandboxing thing should stay purely optional, and normal users should not be bothered with it unless the user explicitly wants it.

[TheAssassin]

I can follow the logic that SUID should be avoided if similar/the same effects can be achieved without needing it.

Well, whether it's suid or userns, it always depends on the implementation whether something is secure. There have been exploits in userns as well. The main security issue with firejail is that it has had such bugs way too often in the past. And a kernel-provided solution is always preferred, mostly because the chance that experts have reviewed a feature thoroughly is way higher than with a third-party provided solution.

At the moment, I consider implementing a standalone system that utilizes bubblewrap/bubblejail as a sandboxing solution, as user namespaces are being adopted by more and more distros, and it's in widespread use in other projects as well. I have no experience with them, but bubblejail looks like a good solution, as it's profile-based and these profiles can hopefully be generated by a nice user-friendly UI that asks for permissions.

It should be clear that such a tool has a dependency on bubblewrap, and I'm not sure whether it'd be a good idea to bundle such a tool for deployment. With AppImageLauncher, I can just add a dependency on the system packages. The Lite version would have to check for a system-wide installed version. I would of course bundle this system with my own AppImageLauncher packages, but in a way so it's optional (always good for distro packaging).

The UI I have in mind should be relatively simple: A set of four or five checkboxes or sliders with simple questions, like, "grant Internet access", "grant access to home directory", etc. I don't think making it more fine grained is a plus in terms of security, as users shouldn't be confused and shouldn't be annoyed too much so they just enable everything. I do want to add some feature to have AppImages suggest/request permissions, like in Android. The UI can warn the user that deactivating one of these permissions can lead to the app not working normally.

One thing should be clear: sandboxing is only a "last defence" against attacks. Obviously, it can't replace the need to run untrusted applications in VMs or, better, not run them at all.

@mgord9518 I suggest you join our IRC channel. See https://docs.appimage.org/contact.html#irc for more information.

[boredsquirrel]

is there any update on this? Where you able to isolate appimages in a userns sandbox?

tbh making it work with fuse sounds so complicated, that even unpacking and repackaging them as flatpak sounds more reasonable. (which have nearly complete GUI support around them, and vast adaption)

[probonopd]

Personally I am not very interested in sandboxing, so I leave this exercise to others.

FUSE is the only hard dependency of AppImage, so if bubblewrap is really "so complicated" to get to work with FUSE (I don't know), then it is probably not useful for running AppImages.

[mgord9518]

It isn't complicated. aisap has used bubblewrap with fuse for about 2 years now, you just have to manually mount it then sandbox it. The hard part is user-friendly profiles

[probonopd]

Closing here, since no further action is planned regarding bubblewrap. Thanks everyone for sharing information!