settings in default.profile and disable-common.inc that break AppImages #3249

bdantas · 2020-02-26T19:37:33Z

I tested two completely different AppImages (Firefox.AppImage, which I downloaded from appimagehub.com, and Xscreensaver.AppImage, which I created from scratch myself) on Tiny Core Linux 64-bit with firejail 0.9.62.

The only way to get these two AppImages to run with firejail is to comment-out the following lines in default.profile:

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

and also comment-out these lines in disable-common.inc:

blacklist ${PATH}/fusermount
blacklist ${PATH}/nc

I discovered the above after much trial and error.

Perhaps firejail could learn to detect AppImages and use a different profile (e.g., default-appimage.profile) and include file (e.g., disable-common-appimage.inc) that do not contain the offending lines above?

@probonopd might also be interested in this information.

The text was updated successfully, but these errors were encountered:

Vincent43 · 2020-02-27T10:25:38Z

Keep in mind that disabling almost all options makes using firejail at all questionable.

bdantas · 2020-02-27T12:13:16Z

That's a good point. Maybe the AppImage runtime could be tweaked to need fewer privileges? Alas, I'm just a user and don't know if that would be doable without crippling functionality.

Vincent43 · 2020-02-27T16:57:35Z

it's not really about appimage runtime but about apps. Having one sandbox fits all results in almost no sandbox because one app needs this, other app needs that and so on. To overcome this we need to differentiate sandbox depending on called app but I don't know how feasible is this with appimages.

bdantas · 2020-02-27T17:18:03Z

I understand what you're saying, but that's not what I was suggesting. I was suggesting a generic profile that allows what all AppImages need in order to mount the squashfs payload via fuse--let's call it the generic "AppImage loading" phase (all AppImages need to be allowed to call fusermount, for example).

After that, sure--we are in app-specific territory where we can't predict what privileges are needed. That's a separate problem that perhaps could be solved by documentation in appimagehub that lets users of a specific AppImage know what additional (if any) application-specific privileges are needed beyond what's in the generic AppImage profile.

glitsj16 · 2020-02-28T02:15:57Z

@bdantas I just saw #2690 again and that reminded me that we have support for using a special ?HASAPPIMAGE: conditional in profiles (0.9.62 and later). Perhaps you can try this instead of commenting in disable-common.inc (so the default profiles are kept fully intact for non-appimage usage):

blacklist ${PATH}/fusermount
?HAS_APPIMAGE: noblacklist ${PATH}/fusermount
blacklist ${PATH}/nc
?HAS_APPIMAGE: noblacklist ${PATH}/nc

See #2690 (comment).

bdantas · 2020-02-28T03:45:28Z

Ok, so I created a barebones AppImage for testing. It does nothing but run this script:

#!/bin/sh
echo hello

The AppImage was created using the latest stable release (version 12) of AppRun-x86_64 and appimagetool-x86_64.AppImage available here: https://github.com/AppImage/AppImageKit/releases

Here is the AppImage if you'd like to inspect it: http://files.dantas.airpost.net/public/Dummy-x86_64.AppImage

The installed firejail is version 0.9.62 which seems to include AppImage support:

$ firejail --version
Error: cannot read UID_MIN and/or GID_MIN from /etc/login.defs, using 1000 by default
firejail version 0.9.62

Compile time support:
	- AppArmor support is disabled
	- AppImage support is enabled
	- chroot support is enabled
	- file and directory whitelisting support is enabled
	- file transfer support is enabled
	- firetunnel support is enabled
	- networking support is enabled
	- overlayfs support is enabled
	- private-home support is enabled
	- seccomp-bpf support is enabled
	- user namespace support is enabled
	- X11 sandboxing support is enabled

I'm running the AppImage in a minimalistic 64-bit Tiny Core Linux machine (linux kernel 5.4.3) with this command in a terminal emulator:

$ firejail ./Dummy-x86_64.AppImage

As was the case with the two AppImages in my original post, Dummy-x86_64.AppImage is only able to echo hello in the terminal if I comment-out these lines in default.profile like this:

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

and also comment-out these lines in disable-common.inc:

#blacklist ${PATH}/fusermount
#blacklist ${PATH}/nc

If I remove the pound sign from any of the lines above, the test AppImage fails to run.

If I have this in disable-common.inc:

blacklist ${PATH}/fusermount
?HAS_APPIMAGE: noblacklist ${PATH}/fusermount
blacklist ${PATH}/nc
?HAS_APPIMAGE: noblacklist ${PATH}/nc

Then the test AppImage also fails to run.

Conclusions:

It seems strange that so much needs to be commented-out in default.profile in order for even a barebones AppImage to run, but that's what I'm finding. It would be nice if someone could reproduce this.
The ?HAS_APPIMAGE trick has no effect in my test.

bdantas · 2020-02-28T04:11:28Z

P.S. I just tested the same Dummy-x86_64.AppImage in a totally different environment (Devuan ASCII with firejail version 0.9.44.8). Results were almost identical to the above. The only differences where these two:

In Devuan it's okay to leave nc blacklisted
The older firejail version complains that the ?HAS_APPIMAGE line is invalid

glitsj16 · 2020-02-28T06:04:27Z

@bdantas Thank you for doing extensive testing. I've made similar tests using your Dummy-x86_64.AppImage referenced above and can confirm (most of) your observations.

If I have this in disable-common.inc:

blacklist ${PATH}/fusermount
?HAS_APPIMAGE: noblacklist ${PATH}/fusermount
blacklist ${PATH}/nc
?HAS_APPIMAGE: noblacklist ${PATH}/nc

Then the test AppImage also fails to run.

As per man firejail the conditional '?HAS_APPIMAGE:' only works when it encounters '--appimage' as argument to the firejail command. At least as far as I can see in your responses throughout this issue that argument hasn't been used, which would explain it not doing anything positive in this context. In fact, using the '--appimage' on CLI (or it's counterpart 'appimage' in a profile file) is the recommended use of firejail with AppImages.

That being said, I can reproduce, so marking this as a bug. Strangely enough firejail --noprofile works (without making any changes to the default profiles) while firejail --noprofile --appimage does not. To me that suggests something is broken in the implementation of that parameter (in https://github.com/netblue30/firejail/blob/1ad2d54c014a49f6ad0b487dd0d9b361cb4d299e/src/firejail/sandbox.c).

rusty-snake · 2020-02-28T07:47:27Z

noblacklist must come before the blacklist.

?HAS_APPIMAGE: noblacklist ${PATH}/fusermount
blacklist ${PATH}/fusermount
?HAS_APPIMAGE: noblacklist ${PATH}/nc
blacklist ${PATH}/nc

rusty-snake · 2020-02-28T07:51:13Z

@bdantas As an workaround to get an default-appimage.profile.

/etc/firejail/default.local:

?HAS_APPIMAGE: include default-appimage.profile

/etc/firejail/default-appimage.profile:

ignore caps.drop all
ignore nonewprivs
ignore noroot
ignore protocol
ignore seccomp

glitsj16 · 2020-02-28T08:37:45Z

Although, as (very) temporary workaround, the contribution of @rusty-snake is technically sound and valid - besides being well intended I'm sure - it is crucial to again remind AppImage users to what @Vincent43 already stated above: crippling firejail in such a way is an excersise in futility. Personally I've always wondered why firejail supports them in the first place and feel tempted to argue for dropping support, like we did for snap and flatpak. Just my 2 cents.

Vincent43 · 2020-02-28T10:55:42Z

I understand what you're saying, but that's not what I was suggesting. I was suggesting a generic profile that allows what all AppImages need in order to mount the squashfs payload via fuse--let's call it the generic "AppImage loading" phase (all AppImages need to be allowed to call fusermount, for example).

Appimages historically worked with firejail --appimage option in most cases just fine. Did something changed recently in appimage runtime? I can reproduce issues with your example but on the other hand this one gui app created month ago work for me with default profile.

Vincent43 · 2020-02-28T11:44:40Z

That's a separate problem that perhaps could be solved by documentation in appimagehub that lets users of a specific AppImage know what additional (if any) application-specific privileges are needed beyond what's in the generic AppImage profile.

After commenting out proposed options in generic Appimage profile there would be no need to add any new privs because all of them would be already allowed for every appimage. Just some binaries and configs will be blacklisted and pid namespace would be used but any app would be able to escalate to full root access if it use some working 0day.

Even with current default profile appimages sandboxing is inferior in comparison with generic apps that use whitelisting but if it's true that current appimage runtime is incompatible with core firejail sandbox features then still calling appimages sandboxed will only get false sense security for users. I agree with comment above that in such case official appimage support should be dropped.

bdantas · 2020-02-28T13:44:30Z

@Vincent43 I tested the AppImage (yubioath-desktop) in the link you provided. Like all the other AppImages I've tried or created myself, it only works in firejail if I use --noprofile or if I cripple default.profile as shown in my previous posts.

I sandboxed some additional applications (non-AppImages) in Tiny Core Linux and it turns out that anytime disable-common.inc is sourced by a profile, the application doesn't work unless I comment-out the line that blacklists nc. So the nc issue is a general firejail issue in Tiny Core Linux and is not specific to AppImages.

Please let the AppImage developers weigh in (especially @probonopd) before you guys make any decisions about official AppImage support in firejail. I'm just a user and know nothing about the internals of AppImage's runtime binary. Perhaps decreasing privilege requirements of the runtime would not be difficult. If that turns out to be the case, the only special consideration the AppImage loading phase would need from firejail is for fusermount to be allowed (via --appimage argument and the special ?HAS_APPIMAGE line in disable-common.inc).

Vincent43 · 2020-02-28T16:59:31Z

So we need to figure out if this is appimage issue, Tiny Core Linux issue or some specific issue to the way you create appimages. On my system I don't even have nc installed.

smitsohu · 2020-02-28T17:26:27Z

I think the solution for the issue around nc is that @bdantas needs to pass enable-busybox-workaround to the configure script before compiling.

bdantas · 2020-02-28T17:40:06Z

I think the first order of business is for me to move all testing to a more traditional distro. I have Devuan on a separate partition on my personal machine--it is a more traditional distro than TCL and uses GNU coreutils rather than BusyBox. I'm going to compile firejail 0.9.62 in Devuan right now.

I'm highly motivated to get to the bottom of this.

bdantas · 2020-02-28T18:01:41Z

Ok, I'm ready to roll:

$ cat /etc/os-release 
PRETTY_NAME="Devuan GNU/Linux ascii"
NAME="Devuan GNU/Linux"
ID=devuan
ID_LIKE=debian
HOME_URL="https://www.devuan.org/"
SUPPORT_URL="https://devuan.org/os/community"
BUG_REPORT_URL="https://bugs.devuan.org/"

$ uname -a
Linux thinkpad 4.16.2-gnu #1 SMP Thu Apr 12 13:27:37 UTC 2018 x86_64 GNU/Linux

$ firejail --version
firejail version 0.9.62

Compile time support:
	- AppArmor support is disabled
	- AppImage support is enabled
	- chroot support is enabled
	- file and directory whitelisting support is enabled
	- file transfer support is enabled
	- firetunnel support is enabled
	- networking support is enabled
	- overlayfs support is enabled
	- private-home support is enabled
	- seccomp-bpf support is enabled
	- user namespace support is enabled
	- X11 sandboxing support is enabled

I will do a few tests and will report back.

bdantas · 2020-02-28T18:23:35Z

@Vincent43 now I think we are on the same page.

I made no changes whatsoever to the files in /usr/local/etc/firejail.

Here are my results:

$ firejail ./yubioath-desktop-5.0.2-linux.AppImage # doesn't work
$ firejail --appimage ./yubioath-desktop-5.0.2-linux.AppImage # works
$ firejail --noprofile ./yubioath-desktop-5.0.2-linux.AppImage # works

$ firejail ./Dummy-x86_64.AppImage # doesn't work
$ firejail --appimage ./Dummy-x86_64.AppImage # doesn't work
$ firejail --noprofile ./Dummy-x86_64.AppImage # works

$ firejail ./Firefox-x86_64-20200118153954.AppImage # doesn't work
$ firejail --appimage ./Firefox-x86_64-20200118153954.AppImage # doesn't work
$ firejail --noprofile ./Firefox-x86_64-20200118153954.AppImage # works

So it seems Dummy and Firefox have the same issue, which does not affect yubioath. The Firefox AppImage is the 72.0.1 version available here: https://www.appimagehub.com/p/1331794/

bdantas · 2020-02-28T18:27:10Z

It seems the issue with Dummy and Firefox has to do with permissions to run bash or AppRun:

$ firejail --appimage ./Firefox-x86_64-20200118153954.AppImage 
Mounting appimage type 2
Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/default.profile
Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/disable-common.inc
Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/disable-passwdmgr.inc
Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/disable-programs.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 18842, child pid 18845

**     Warning: dropping all Linux capabilities     **

Child process initialized in 86.21 ms
/bin/bash: /run/firejail/appimage/.appimage-18842/AppRun: Permission denied

Parent is shutting down, bye...
AppImage unmounted

$ firejail --appimage ./Dummy-x86_64.AppImage Mounting appimage type 2
Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/default.profile
Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/disable-common.inc
Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/disable-passwdmgr.inc
Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/disable-programs.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 18900, child pid 18903

**     Warning: dropping all Linux capabilities     **

Child process initialized in 116.30 ms
/bin/bash: /run/firejail/appimage/.appimage-18900/AppRun: Permission denied

Parent is shutting down, bye...
AppImage unmounted

rusty-snake · 2020-02-28T18:31:36Z

#2690 (comment)

bdantas · 2020-02-28T18:37:16Z

Thanks, @rusty-snake. So I tried changing AppRun ownership to root:root and permissions to 755, no luck. Also tried 775, no luck.

EDIT: Ooooh, I see. The permisisons issue is on the /run/firejail/appimage/.appimage-XXXX/ directory, not on the AppRun binary. Gosh, how do I get the right permissions? I don't see an obvious solution in that thread.

rusty-snake · 2020-02-28T18:51:18Z

firejail/src/firejail/appimage.c

Lines 98 to 123 in dc12ce6

    
           // creates appimage mount point perms 0700 
        
           if (asprintf(&mntdir, "%s/.appimage-%u",  RUN_FIREJAIL_APPIMAGE_DIR, getpid()) == -1) 
        
           	errExit("asprintf"); 
        
           EUID_ROOT(); 
        
           mkdir_attr(mntdir, 0700, getuid(), getgid()); 
        
           EUID_USER(); 
        
           // mount 
        
           char *mode; 
        
           if (asprintf(&mode, "mode=700,uid=%d,gid=%d", getuid(), getgid()) == -1) 
        
           	errExit("asprintf"); 
        
           unsigned long flags = MS_MGC_VAL|MS_RDONLY; 
        
           if (getuid()) 
        
           	flags |= MS_NODEV|MS_NOSUID; 
        
           EUID_ROOT(); 
        
           if (size == 0) { 
        
           	fmessage("Mounting appimage type 1\n"); 
        
           	if (mount(devloop, mntdir, "iso9660", flags, mode) < 0) 
        
           		errExit("mounting appimage"); 
        
           } 
        
           else { 
        
           	fmessage("Mounting appimage type 2\n"); 
        
           	if (mount(devloop, mntdir, "squashfs", flags, NULL) < 0) 
        
           		errExit("mounting appimage"); 
        
           }

bdantas · 2020-02-28T18:58:58Z

@rusty-snake pardon my ignorance, but I don't understand. Is this part of firejail's source code the problem or the solution? If the solution, are you saying I should use latest git instead of 0.9.62?

At any rate, it seems that I've beaten this to death. There turned out to be multiple pseudo-issues and just one real issue that's already known. Sorry for the noise.

probonopd · 2020-03-07T20:27:02Z

What if you change

firejail/src/firejail/appimage.c

Line 102 in dc12ce6

mkdir_attr(mntdir, 0700, getuid(), getgid());

from 0700 to 0755?

rusty-snake · 2020-03-07T20:50:42Z

Nothing ☹️

glitsj16 mentioned this issue Feb 28, 2020

Some AppImages break, "Permission denied" #2690

Open

glitsj16 added the bug Something isn't working label Feb 28, 2020

bdantas mentioned this issue Feb 28, 2020

Create Xscreensaver AppImage/appimage.github.io#1909

Closed

bdantas closed this as completed Feb 28, 2020

bdantas mentioned this issue Mar 9, 2020

Firejail can't run AppImages made with appimagetool AppImage/AppImageKit#1032

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

settings in default.profile and disable-common.inc that break AppImages #3249

settings in default.profile and disable-common.inc that break AppImages #3249

bdantas commented Feb 26, 2020 •

edited

Loading

Vincent43 commented Feb 27, 2020

bdantas commented Feb 27, 2020

Vincent43 commented Feb 27, 2020

bdantas commented Feb 27, 2020 •

edited

Loading

glitsj16 commented Feb 28, 2020

bdantas commented Feb 28, 2020 •

edited

Loading

bdantas commented Feb 28, 2020 •

edited

Loading

glitsj16 commented Feb 28, 2020

rusty-snake commented Feb 28, 2020

rusty-snake commented Feb 28, 2020

glitsj16 commented Feb 28, 2020

Vincent43 commented Feb 28, 2020

Vincent43 commented Feb 28, 2020

bdantas commented Feb 28, 2020 •

edited

Loading

Vincent43 commented Feb 28, 2020

smitsohu commented Feb 28, 2020

bdantas commented Feb 28, 2020 •

edited

Loading

bdantas commented Feb 28, 2020

bdantas commented Feb 28, 2020

bdantas commented Feb 28, 2020 •

edited

Loading

rusty-snake commented Feb 28, 2020

bdantas commented Feb 28, 2020 •

edited

Loading

rusty-snake commented Feb 28, 2020

bdantas commented Feb 28, 2020 •

edited

Loading

probonopd commented Mar 7, 2020

rusty-snake commented Mar 7, 2020

settings in default.profile and disable-common.inc that break AppImages #3249

settings in default.profile and disable-common.inc that break AppImages #3249

Comments

bdantas commented Feb 26, 2020 • edited Loading

Vincent43 commented Feb 27, 2020

bdantas commented Feb 27, 2020

Vincent43 commented Feb 27, 2020

bdantas commented Feb 27, 2020 • edited Loading

glitsj16 commented Feb 28, 2020

bdantas commented Feb 28, 2020 • edited Loading

bdantas commented Feb 28, 2020 • edited Loading

glitsj16 commented Feb 28, 2020

rusty-snake commented Feb 28, 2020

rusty-snake commented Feb 28, 2020

glitsj16 commented Feb 28, 2020

Vincent43 commented Feb 28, 2020

Vincent43 commented Feb 28, 2020

bdantas commented Feb 28, 2020 • edited Loading

Vincent43 commented Feb 28, 2020

smitsohu commented Feb 28, 2020

bdantas commented Feb 28, 2020 • edited Loading

bdantas commented Feb 28, 2020

bdantas commented Feb 28, 2020

bdantas commented Feb 28, 2020 • edited Loading

rusty-snake commented Feb 28, 2020

bdantas commented Feb 28, 2020 • edited Loading

rusty-snake commented Feb 28, 2020

bdantas commented Feb 28, 2020 • edited Loading

probonopd commented Mar 7, 2020

rusty-snake commented Mar 7, 2020

bdantas commented Feb 26, 2020 •

edited

Loading

bdantas commented Feb 27, 2020 •

edited

Loading

bdantas commented Feb 28, 2020 •

edited

Loading

bdantas commented Feb 28, 2020 •

edited

Loading

bdantas commented Feb 28, 2020 •

edited

Loading

bdantas commented Feb 28, 2020 •

edited

Loading

bdantas commented Feb 28, 2020 •

edited

Loading

bdantas commented Feb 28, 2020 •

edited

Loading

bdantas commented Feb 28, 2020 •

edited

Loading