mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #527] Firejail does not work with OrbitalApps portable applications #370
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#370
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 @igor2x on GitHub (May 19, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/527
Hi,
OrbitalApps are designed to work on Ubuntu 16.04 Desktop 64-bit. Other Linux distributions are not tested and may not work.
firejail --versionOutput is: firejail version 0.9.38
orb vlc_2.2.2_portable_64bits.orbAnd application outputs the following info and applications starts up successfully.
Note: Above are some errors probably because I run it using VirtualBox. But VLC Media Player application starts up and working fine.
9. Close down VLC Media Player.
10. Now start the same program by prefixing firejail:
firejail orb vlc_2.2.2_portable_64bits.orbBellow info is outputed but VLC Media Player never starts up.
It looks to me that some special firejail profile should be created for OrbitApps portable.
Regards
@netblue30 commented on GitHub (May 20, 2016):
The program is crashed by seccomp. They try to do a mount syscall. If you disable seccomp in the profile file, then you would also need to disable capabilities in order to give the program administrative rights, because they also run SUID binaries to mount the ISO filesystem. The bad part comes when you start running the programs in the ISO filesystem. There can be anything in there, and they have admin rights.
I would stay away form this type of applications, they are the modern equivalent of clicking on email attachments.
@igor2x commented on GitHub (May 21, 2016):
Thanks a lot for looking into this problem and providing your precious opinion. I just saw an article on web about portable applications. I love idea of PortableApps.com portable applications on Windows, you know running application from USB key without installation, where no superuser is required to run applications and all of the config files are saved on USB key, excellent idea for portability. But as it looks like OrbitalApps portable applications on Ubuntu 16.04 the idea is the same, but implementation is pretty much very different.
If I understand you correctly in the case of OrbitalApps portable application it is not a case for slightly adjust one of the Firejail profile to disable insignificant security features in Firejail, but critical component has to be disabled (allowing super user access). In this case there is very difficult or impossible to jail such an application. Application having superuser access is in no real point of jailing it anyway. Using this kind of portable application it is in no way possible to have portability and security at the same time. User concerned about security like me should not use OrbitalApps portable applications, because it is impossible to secure them properly like jailing them.
You can close this problem request with some status of not been possible to securely fix the problem and so problem report is irrelevant to Firejail.
Thanks a million for your precious opinion.
@pcx862 commented on GitHub (May 22, 2016):
Hi, I'm the lead developer of ORB Applications and would like to clear some misconceptions:
*By design, our "ORB Launcher" never runs as root
*By design, we never use SUID
*By design, our apps don't run as root
*By design, the sudo password is always expired, so the ISO contents can never take advantage of the sudo password in the cache
In addition, not just the the ORB/ISO itself is cryptographically signed, but the contents are also signed (a file with all the SHA512 hashes is PGP-signed)
We believe we have a robust multi-layered security model, as can be seen here:
https://www.orbital-apps.com/security
Having clarified that, we are very interested in making our apps compatible with firejail, and even further, we plan to integrate firejail and enable sandboxing by default.
Regarding this specific issue, it seems if (non-root) FUSE operations (mount) can be sandboxed with seccomp, everything else should work perfectly.
Are non-root FUSE operations blocked by design? Is there a way to "whitelist" FUSE operations but leave everything else enabled?
Thanks in advance for a possible solution,
Peter M
@netblue30 commented on GitHub (May 23, 2016):
Sorry if I went overboard in my previous comment.
FUSE ends up calling a SUID binary (/bin/fusermount) to mount the filesystem. In order to run it, you would need CAP_SYS_ADMIN capability enabled (man 7 capabilities). All capabilities are disabled by the sandbox. You would also need to disable seccomp. seccomp uses an obscure kernel feature, no_new_privs https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt , for its own protection. This also disables SUID binaries.
The way it could work, in your starter program after FUSE mounting, start the application in the sandbox. Instead of "vlc" you would need to start "/usr/bin/firejail vlc". If the user doesn't have firejail installed, you just start "vlc" as usual. Or you can open a dialog window and ask the user, but basically it should work.