[appimaged] Use different firejail profiles for sandboxing about appimaged HOT 15 OPEN

Preparing a patch, should not take long.

from appimaged.

Current development version: 0.9.41 specifically adds an --appimage parameter that lets us run AppImages very comfortably inside the sandbox.

https://github.com/netblue30/firejail

from appimaged.

appimaged uses firejail to run AppImages when it is installed.

from appimaged.

This is fantastic news. Of the many implementations, AppImage (Digikam AppImage precisely) is what I used first and really liked it. Today, I spent a good chunk of time exploring Flatpak and Snap.

Of the 3, I really love the simplicity AppImage has. The only thing concerning was sandboxing. I think sandboxing should be a pre-requisite for appimage. Or instead, every appimage appliance should have an option to be run with/without firejail/sandboxing.

Because AppImages will most commonly be used for 3rd party software or New/Unofficial/Pre-Release versions of software. Running such software should mostly happen in a jailed environment.

from appimaged.

True. appimaged has the basic infrastructure for this in place. Add some signature checking and webs-of-trust, and we can make this happen. Do I hear a volunteer @rickysarraf?

from appimaged.

from appimaged.

I have been wanting to do this. But like I said, I'm pretty new to these tools.

Excellent, feel free to look around here, and ask questions if you find something is unclear. There is also a forum at http://discourse.appimage.org/

My intent also is to get appimaged and other helper tools, packaged for Debian. I'm a Debian Developer, love the concept of AppImage, and see these tools as a good fit to be packaged for Debian.

That would be very worthwhile. Also see this (although that ticket is about RPM most will be applicable for deb too).

I haven't looked into the implementation yet, but what I desire AppImage to do, is to stick to its ./foo.appimage way of execution, irrespective of running sandboxed (through firejail) or just plain. Within the appimages should be the logic to test if firejail is available, and if available, to use it by default. All of this should be transparent to the user.

Isn't that a logic problem?

The point of a sandbox is that the user does not fully trust the AppImage. Hence any mechanism that invokes the sandboxing from inside the AppImage itself is futile by definition, because the user can only trust a sandbox and its invocation if this happens from the (trusted) outside of the sandbox.

This is why I foresee two ways to execute a downloaded AppImage:

1. By manually setting the executable bit and therefore marking the AppImage as fully trusted, or
2. By using the optional appimaged daemon which does not set the executable bit when Firejail is installed, but runs the AppImage inside Firejail (this is already implemented, although without any restrictions in the Firejail profile so far; one could give a properly signed AppImage more permissions than an unsigned one or do something like Android which asks the user for specific permissions).

Or am I missing something there?

from appimaged.

If someone is interested in beefing up Firejail security in appimaged, please discuss with us how we could get a good customer experience. @netblue30 could you recommend a few generic profiles (better than nothing) or would we have to integrate something like https://github.com/netblue30/firejail/tree/master/etc (sounds like a lot of work and cluttered user experience)?

How is Apple doing the sandboxing for the Mac App Store?

from appimaged.

What would be the upside/downside of using Firejail vs. AppArmor?

from appimaged.

When running AppImage archives, unless the user requests a specific profile, Firejail picks up /etc/firejail/default.profile. This is the most restrictive generic profile we have, it looks something like this:

include /etc/firejail/disable-common.inc
include /etc/firejail/disable-programs.inc
include /etc/firejail/disable-passwdmgr.inc

caps.drop all
netfilter
nonewprivs
noroot
protocol unix,inet,inet6
seccomp

"include /etc/firejail/disable-common.inc" disables all known password and encryption files in home directory, "include /etc/firejail/disable-programs.inc" disables program configuration for about 250 common programs such as Firefox and VLC, and "include /etc/firejail/disable-passwdmgr.inc" disables the storage files for several password managers.

This profile is also used for regular executables installed on the system. The way is working is if Firejail cannot figure out what program the user is requesting, it will use this profile - the name of the program is extracted from argc/argv params in main() function.

What we are missing for AppImage archives is a way for Firejail to extract the name of the real program. All I have in this moment is AppRun executable inside the image.

I can also try to guess it from the name of AppImage archive. For example Leafpad-0.8.17-x86_64.AppImage could become /etc/firejail/leafpad.profile - convert to lowercase and grab the first word.

Either way we go, it would be easy to implement on my side. I can even go with a combination of the two.

Re AppArmor:

Some people use Firejail on top of AppArmor or SELinux. There are only a few profiles for GUI programs available, about 5 of them for AppArmor and none for SELinux. Another problem is availability - basically you get SELinux on RedHat distros and AppArmor on Ubuntu distros. On all other distributions the user has to install them manually.

from appimaged.

Please move it to the appimaged repo

from appimaged.

Firejail support was lost at some point when moving to libappimage

from appimaged.

Firejail support was lost at some point when moving to libappimage

Oops, what do you mean by "Firejail support was lost"? I mean, we never did anything specific to support it...

from appimaged.

From the readme

Optionally you can use a sandbox if you like: If the firejail sandbox is installed, it runs the AppImages with it.

That's exactly was was lost.

from appimaged.

Ah, I see what you mean. Can you restore it? (Shouldn't be too hard.)

from appimaged.