[appimaged] Use different firejail profiles for sandboxing

[probonopd]

Firejail is a SUID program that reduces the risk of security breaches by restricting the running environment of untrusted applications using Linux namespaces and seccomp-bpf. It allows a process and all its descendants to have their own private view of the globally shared kernel resources, such as the network stack, process table, mount table.

Written in C with virtually no dependencies, the software runs on any Linux computer with a 3.x kernel version or newer. The sandbox is lightweight, the overhead is low. There are no complicated configuration files to edit, no socket connections open, no daemons running in the background. All security features are implemented directly in Linux kernel and available on any Linux computer.

https://firejail.wordpress.com/

Pros:

• Seems to do what we are looking for.
• Lightweight on dependencies.

Cons:

• Sandbox profiles for each application must be specifically written, e.g, "Iceweasel/Mozilla Firefox, Chromium, Midori, Opera, Evince, Transmission and VLC"
• Needs suid
• Hence needs to be installed into the host OS
• Hence needs root rights to set it up

[probonopd]

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

[probonopd]

appimaged uses firejail to run AppImages when it is installed.

[rickysarraf]

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.

[probonopd]

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?

[rickysarraf]

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

On Wed, 2017-01-04 at 12:39 -0800, probonopd wrote: 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?

I have been wanting to do this. But like I said, I'm pretty new to these tools. 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. So, If nobody else picks it up in the coming weeks, I'll take it up for Debian (and automatically its derivatives). On the other hand, I think there's more room for improvement. 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. - -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlhuKzsACgkQpjpYo/Lh dWm+whAAibvDyIRVm6uX2rW+smRwaXVOarsGwNKZc/DqTOMvcamYH12HWD1TGXIw 7pX0fmT75xOixZmpu2fHcNfKJJ7zlBLkbTyQqhpb45ApqvABuVB2l/BAUx16y8vm 8Qk8yVGEFEvc76B4v+VVlRvVb/sIlHAvSrFZpHkx0N+9Ye6HAzfc86JqIzKYtZoo ywjYZTo4xg07mX1sABE/FAgbrU8V5Cn8AG4zMLxtt675P+79yYYphiifAmiEfkir ovOajW7ZPzRoOlKVISlNLO8wc0Wbzv2KhjYugk/LLJs8VtDpFo2twb9dA9p8DpVK /HgY6KHOFfWzmUlOfFNfSBC42Vfz/6iibqtHcFucq6dVgzNIsfWWnDB2z6W2hhtn 9HOaURQAwwG6U9UKjj2IMmBiN4qCUo/QbU3GksKLN8J9YqGchqOFoFTYJ4YAIq3G RTAUbhQ0pNKlFHQ9dhfmILN7p+rGDj56Acvfgegc4HPIXODU30+1sG6Flw9RxFCj +CVy5yK79eaTrB99SjsUNwu7SMUQpa385jHpdfn79r02KSyCcdsRNRsOAlklP0uQ U56v22Ospz1S00NewZ1XekI2NLhQwFmje6NaVIjk1jycxFmolVf8AJczNaHcwqty HAj+Etskh5+mgFuJmciV+zP6sJtq00lu1a+XAp9lhoXlVnI0AbQ= =vUUf -----END PGP SIGNATURE-----

[probonopd]

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?

[probonopd]

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?

[probonopd]

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

[netblue30]

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.

[azubieta]

Please move it to the appimaged repo

[azubieta]

Firejail support was lost at some point when moving to libappimage

[probonopd]

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...

[azubieta]

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.

[probonopd]

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

[azubieta]

Preparing a patch, should not take long.