mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3343] rambox: fails to start #2097
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#2097
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 @ghost on GitHub (Apr 10, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3343
Describe the bug
rambox application doesn't start, core dumped.
Behavior change on disabling firejail
rambox runs right with --noprofile:
To Reproduce
Just execute
ramboxorfirejail rambox.Expected behavior
Rambox application should start and not generate a core dumped. I think the problem is related with seccomp because if I ignore it, application starts:
Desktop (please complete the following information):
@ghost commented on GitHub (Apr 10, 2020):
The output you posted seems to suggest you're using
firecfgto provide desktop integration for firejail, correct? In that case you will have to use the full path to the rambox executable, likefirejail --profile=rambox /usr/bin/ramboxto get reliable output.That being said, electron-based applications (still) suffer from a bug and need some fixing related to seccomp, which is indeed part of the issue here apparently. Can you try with
seccomp !chrootinstead of seccomp please? It would be rather a big loss in the strength of our rambox profile if it would require the whole seccomp filter to be dropped. So if you could confirm it works once you feed it 'seccomp !chroot' we can fix the rambox profile accordingly and in a more secure way.@ghost commented on GitHub (Apr 10, 2020):
I checked again the default profile provided for rambox in firejail 0.9.62 and the default rambox profile fails:
However, it works with
seccomp !chrootconfigured in my~/.config/firejail/rambox.profile:@ghost commented on GitHub (Apr 10, 2020):
@chrpinedo Just installed rambox-bin from AUR and I can reproduce. It confirms my earlier posting and we have a fix in git master now. The rambox profile does indeed need 'seccomp !chroot' for it to work properly. Until the fix gets into a future release, you should be fine by adding that to your rambox.local. One other thing. If your rambox files are installed under /opt/rambox, you can further harden the profile by adding 'private-opt rambox', so it can't see anything else you might have installed under /opt. Feel free to re-open if you need anything else.
@ghost commented on GitHub (Apr 10, 2020):
Thanks for the
private-opt rambox, I am beginning with firejail and I appreciate it. Regards!