mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #2690] Some AppImages break, "Permission denied" #1695
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#1695
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @probonopd on GitHub (May 11, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2690
Some AppImages break with
Permission denied:For example:
References:
@rusty-snake commented on GitHub (May 11, 2019):
May related to #2671.
@rusty-snake commented on GitHub (May 31, 2019):
@probonopd firejail 0.9.49 is old, have you try it with the lastest firejail version?
@probonopd commented on GitHub (Jun 1, 2019):
Yes:
@probonopd commented on GitHub (Jun 7, 2019):
Why is this? We also have the same issue with PhotoGIMP now.
@rusty-snake commented on GitHub (Jun 7, 2019):
=>
/run/firejail/appimage/.appimage-XXXXXis owned by root and has 700.@probonopd commented on GitHub (Jun 8, 2019):
Apparently the permissions for non-root users are missing in the squashfs image. What is interesting, though, is that the native AppImage implementation (using squashfuse) can still use those, but Firejail cannot. Is this because Firejail uses the kernel to mount the squashfs image?
@sudo-give-me-coffee commented on GitHub (Jun 23, 2019):
How to make permissions in the right way?
Currently:
chmod 755
Defined in:
bd49641623/makePhotoGIMP.sh (L86)This produces the following permissions:
Teorically at least
AppRunshould be run:But not occurs:
@rusty-snake commented on GitHub (Jun 23, 2019):
@sudo-give-me-coffee (nice name 😉)
/run/firejail/appimage/.appimage-4148/AppRunmay have the right permissions, but/run/firejail/appimage/.appimage-4148has the wrong.@sudo-give-me-coffee commented on GitHub (Jun 23, 2019):
I understood, so for now, the ideal is to mount the AppImage outside the sandbox?
@probonopd commented on GitHub (Jun 23, 2019):
I wonder why some AppImages have the wrong permissions there (most AppImages are correct).
In any case, it looks like Firejail is behaving correctly.
@crass commented on GitHub (Jul 8, 2019):
Actually, I would say that firejail does the wrong thing here.
First a surprising (at least to me) example. I took the tutanota appimage which also has this issue (#2831), and exctracted the squashfs image from the appimage. Then I mounted it with squashfuse:
So, mounting with squashfuse as a normal user, I can access the contents of the root of the squashfs directory, even though the permissions on the directory clearly indicate it shouldn't be allowed!
If I mount via fuse but as root, a normal user cannot access the contents of the root of the squashfs directory, and strangely can not even get information on the directory itself!
When mounting via loopback using the squashfs kernel fs module, things work as expected.
Ok, this is important because appimage will use fuse to mount the embedded squashfs as the invoking user (in this case a regular user). However, firejail will mount the squashfs using the squashfs kernel module. While it might seem like a security issue for the permissions to be ignored when using fuse and accessing the squashfs root directory, I don't believe there's a problem because the files are all read only.
So I'm thinking that firejail should instead use the appimage binary to fuse mount itself. Using strace on the appimage shows that first
mount("tutanota-desktop-linux.AppImage", "/tmp/.mount_tutanobofSI7", "fuse.tutanota-desktop-linux.AppImage", MS_RDONLY|MS_NOSUID|MS_NODEV, "fd=<fuse dev fd>,rootmode= 40000,user_id=<uid>,group_id=<gid>")is tried, but for fails a regular user withEPERM. Then it tries to use the help:execve("/bin/fusermount", ["fusermount", "-o", "ro,nosuid,nodev,subtype=tutanota-desktop-linux.AppImage", "--", "/tmp/.mount_tutanobofSI7"], <env>). I suggest we use this method instead. Any objects? better ideas? thoughts?@probonopd commented on GitHub (Jul 9, 2019):
So I would say the FUSE-based AppImage runtime is actually doing the wrong thing.
@crass commented on GitHub (Jul 9, 2019):
@probonopd, so if I understand you correctly, you're saying that the permissions should not be ignored by the fuse fs. Correct me if I'm wrong. If that's what you want then the AppImage runtime should be changed to add
default_permissionsto the fuse mount options here.You can test that
default_permissionswill deny access if non-root and allow access with root with the tutanota appimage by using this command:squashfuse -o ro,offset=$(./tutanota-desktop-linux.AppImage --appimage-offset),default_permissions ./tutanota-desktop-linux.AppImage /mntFrom
mount.fuseman page:The annoying thing is that we'll have to get offending appimage builders to build a fixed appimage, which may or may not even be feasible (in the case of abandoned appimages with this issue). And I don't see this as actually adding any extra security. On the brightside, it seems that not a lot of appimages have this issue.
Relatedly, we may still want to make the modifications I suggested because I think it would be a way to future proof our appimage mounting code. We should be letting appimage figure out how to mount itself, rather than us emulating appimage code. So when AppImage Type 3 comes out with the next best compressed filesystem, we won't have to make any code modifications.
@probonopd commented on GitHub (Jul 9, 2019):
@crass thanks for your detailed analysis.
Yes, I think that would produce the same errors that we see with Firejail now in non-Firejail setups as well, hopefully leading to application developers seeing and fixing those permissions errors, resulting in less issues when using AppImages with Firejail. At least that was my line of thinking.
You have a point there, but doesn't it mean it would reduce performance?
@crass commented on GitHub (Jul 9, 2019):
I think moving forward it would be great for AppImage to more strictly enforce perms. But I'm not sure how long it'll take all the offending appimage builders to incorporate the change. In the meantime, we can make it less painful for users wanting to use these appimages (and less issues for us!). If there was a security issue, then I'd be much less accommodating.
What's your thinking on where the performance reduction would be coming from? As I see it, there will be a negligible hit to performance. The place I see for the most performance degradation would be from all file access needing to go through FUSE. But that's what native appimage currently does. Both appimage and firejail have some impact on performance (both seem unnoticeable in my experience). So what I'm proposing would performance-wise look like the performance impact of appimage + impact of firejail, which I suspect will be negligible. Maybe I'm missing something though.
@crass commented on GitHub (Jul 10, 2019):
After looking at fuse a bit more, its not possible to use the appimage to mount itself using the
mountsystem call (ie without executing the appimage). This is obvious now, the binary has the user-space code that emulates the filesystem (squashfs in this case), so of course some of its code will need to be executed.So I see two roads forward here:
appimage --appimage-mount(as normal user of course) to fuse mount the appimage. This is ideal, except that we can not specify a mount directory, a temporary one is automatically generated usingmkdtemp. We could then move the mount to where we like it in/run/firejail. Then before firejail exits, it would send SIGINT to the appimage process, which means we'd need to keep track of the pid. The other problem with this approach is that type 1 appimages don't have the--appimage-mountoption. So the change would need to keep the existing code that handles type 1 appimages.squashfuseandappimage --appimage-offsetto fuse mount the appimage. This method is nice because we don't need to keep track ofsquashfusepid. We just spawnfusermount -u /mntdirto clean up. However, it creates a dependency onsquashfuseand we'd needfuseiso9660for appimage type1. That makes this option a non-starter.Ok, I think I've convinced myself that its not worth the trouble to change firejail for the moment. Perhaps it'll be worth using the appimage to mount itself if there become a lot of appimage types in the future.
@kakasync commented on GitHub (Jan 26, 2020):
I have this problem with onlyoffice, may I know, how to fix it? thanks.
@probonopd commented on GitHub (Feb 27, 2020):
@bdantas offers new insights into this in https://github.com/AppImage/appimage.github.io/pull/1909#issuecomment-590673608:
Can you confirm? Is this something that could be fixed in Firejail?
@ghost commented on GitHub (Feb 28, 2020):
@probonopd Yes, we can fix this by conditionally blacklisting ${PATH}/fusermount via ?HASAPPIMAGE: trickery in disable-common.inc:
#3249 also mentions needing to noblacklist ${PATH}/nc.
I propose to wait a bit on confirmation by affected users that this indeed fixes things. We'll merge this in as soon as that arrives. Support for '?HASAPPIMAGE:' is available from firejail 0.9.62 onwards, so this shouldn't pose any problems IMHO.
@bdantas commented on GitHub (Feb 28, 2020):
@probonopd Just unblacklisting fusermount is not enough. I've done much more extensive testing since that post, and things are much more clear now. Please see here: https://github.com/netblue30/firejail/issues/3249
EDIT: Sorry, it seems that after even more testing I Ianded right back here on this permissions issue.
@bdantas commented on GitHub (Feb 28, 2020):
Is there a workaround for this? How do we get the appropriate permissions? I don't mind taking an even more manual approach (e.g., creating the squashfs archive in one step, ensuring appropriate permissions, then adding the runtime as a separate step).
@bdantas commented on GitHub (Feb 29, 2020):
It seems appimagetool may be to blame.
If AppImage is created manually with mksquashfs and cat (instead of using appimagetool), then this "Permission denied" problem goes away.
See https://github.com/AppImage/AppImageKit/issues/1032#issuecomment-592859774
@Vincent43 commented on GitHub (Feb 29, 2020):
Thx for digging into it. Fixing it in appimagetool would be appreciated as fixing it in firejail as shown in https://github.com/netblue30/firejail/issues/2690#issuecomment-509901803 is quite complicated.
@probonopd commented on GitHub (Mar 7, 2020):
@shoogle found out that when used with Firejail, the mount point for the AppImage is
rwxfor root and nobody else. Do you know why this is, and could it be changed? All files inside AppImages produced by appimagetool (and apparently also the directory that gets mounted to the mountpoint) are owned by root, and we would prefer to keep it that way.dc12ce6a06/src/firejail/appimage.c (L98-L102)may be the culprit? What would happen if we would use
0755instead of0700there?@rusty-snake commented on GitHub (Mar 7, 2020):
@probonopd see https://github.com/netblue30/firejail/issues/2690#issuecomment-500023512, the irrational think is that some AppImages work with firejail and other not. @netblue30 any reason why this is owned by root and 7000?
Maybe also here:
dc12ce6a06/src/firejail/appimage.c (L107)@probonopd commented on GitHub (Mar 7, 2020):
@rusty-snake
Maybe we found out why: Some AppImages have all files inside the squashfs owned by root and some don't. @bdantas showed in https://github.com/AppImage/AppImageKit/issues/1032 that it works when the files are not owned by root, and it fails when the files are owned by root.
@Vincent43 commented on GitHub (Mar 8, 2020):
It seem two conditions make same appimages broken:
mounting filesystem with 700 permissions, aka only owner has access (done by firejail)It's interesting that initial appimage support used 755 permissions and was changed later to 700 without much explanation. Maybe restoring initial mode will fix this?
EDIT: here are some explanations for above change, although not explicitly about 700 vs 755.
@smitsohu commented on GitHub (Mar 8, 2020):
I just tried, unfortunately it doesn't help.
Also since
3740f37648we don't pass these options any more to the squashfs mount, to work around a regression in the kernel.@Flashwalker commented on GitHub (Aug 4, 2022):
So what's the fix?