mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #359] firefox: program is automatically started outside of firejail (KDE Plasma) #256
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#256
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 @RonCam on GitHub (Mar 8, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/359
System info: Linux Mint Rosa/17.3 / KDE
I recently thought to double-check to make sure Firefox was protected in the sandbox - opened Firejail Tools (the only way I know to verify this) - and saw the list was empty - so Firefox had been running unprotected, and I didn't realize it.
Problem: Firejail was initially started along with Firefox by using one of the modified 'shortcuts', but then, when the computer was was shut down, and later restarted with Session Management set to 'Restore' -- the software from the prior session was restarted, returning the system to the same state as as it was, when the computer was last turned off.
That is, it returned to the same state with the exception of Firefox, which was now running 'outside' of the sandbox.
Is there any way to set the operating system to automatically trigger Firejail to begin running, with Firefox 'inside' it, when the system is powered-up, causing the previous session to be restored?
I generally keep the Session Restore feature active, for the convenience of just pushing the 'Power On' button and then knowing when I return to the computer I'll be seeing the Desktop just as I left it, the day before.
If it can be avoided, I'd rather not lose this feature for the browser. Any ideas?
@chiraag-nataraj commented on GitHub (Mar 8, 2016):
Hmmm...depends on how exactly KDE is storing the session data. If, as I think, it stores links to the desktop files to invoke on login, you can modify the .desktop files in /usr/share/applications/ to launch firefox with firejail.
@RonCam commented on GitHub (Mar 8, 2016):
That's a good idea.
If you're not running KDE, let me list the three choices for the type of Session Restoration:
I opened the /usr/share/applications directory in a file manager, then firefox.desktop in a text editor, went down to the first location where I saw the executable, in a section called [Desktop Action NewWindow]. Then, editing that line, we now have this (showing both old, and new):
I'll begin using this, and see if firefox's behavior following Session Restoration has improved. Any other ideas?
@chiraag-nataraj commented on GitHub (Mar 8, 2016):
Let's see if that works. If it doesn't, I'll need more information about exactly where option 1) gets its data from (ostensibly from something in ~/.config/?).
@RonCam commented on GitHub (Mar 9, 2016):
Unfortunately, Firefox still opens outside of the sandbox.
Since I modified the other file, Firejail Tools now opens with a terminal icon to the right of the Firefox icon. Clicking on this terminal icon opens a sandboxed terminal session.
Does this suggest to you that the way I entered the Firejail prefix was incorrect, and some correction would make Firefox, rather than terminal, become sandboxed? By the way, I didn't mean to say, the terminal running sandboxed -- that only happens after the icon is clicked.
Session data is stored in: ~/.kde4/share/config/ksmserverrc
Scroll to bottom of page.
The file has a current date, so it's likely being dynamically created. Line #166 is as follows:
restartCommand15=/usr/bin/firefox,--sm-config-prefix,/firefox-NZfSzp/,--sm-client-id,1014214b158111000145743645800000020540031,--screen,0But it's not immediately apparent where the firejail prefix should be added. Any ideas?
@RonCam commented on GitHub (Mar 9, 2016):
Hold the press: I just found line #147:
program15=firefoxI wonder if that's a static entry?
Unless you see anything else, let me try that during the day, tomorrow, when I'll be able to resume working on this problem.
😃 Many thanks for the progress so far, and please review what's been done and let me know if you discover going in a different direction might be more productive.
@chiraag-nataraj commented on GitHub (Mar 9, 2016):
Hmmm...it seems when KDE saves its session, it doesn't realize the command was
firejail firefoxand not justfirefox. Since the file is being automatically created, I'll have to think about how exactly you'd rectify this...I'm going to install KDE in a VM and explore a bit.
@RonCam commented on GitHub (Mar 9, 2016):
Thanks for going to the trouble, to help me (and other KDE-users who like Firejail).
Please note, my system information is in the first line of my first post, of this thread. That will narrow it down, as to the version of KDE.
You seem to have a good grasp on what's going on here, 'behind the scenes' -- so maybe best if I wait for your next post, instead of changing things at random ... 😕
@netblue30 commented on GitHub (Mar 9, 2016):
You can also make a symbolic link (ln -s) to /usr/bin/firejail under the name of the program you want to run, and put the link in /usr/local/bin):
This works in most of cases. It will trick the system to launch a jailed firefox instead of the regular firefox.
@RonCam commented on GitHub (Mar 9, 2016):
This sounds interesting.
Question: would this also make it unnecessary to individually and manually modify any and all other links on the system, pointing to Firefox? This refers to links that may be on the Desktop, in the Application Launcher, etc., etc.
@chiraag-nataraj commented on GitHub (Mar 9, 2016):
@netblue30 is right. Since these entries are automatically being created at logoff, the best bet is to modify what "firefox" refers to. The easiest way to do that is to create a symbolic link as suggested.
If it were linking to .desktop files, the matter would be completely different.
@netblue30, do you know why exactly it's not picking up on the command as
firejail firefoxinstead offirefox? Or is it recording both and thus not properly launching the sandbox?@netblue30 commented on GitHub (Mar 9, 2016):
I can see in my case (LXDE) the symbolic link fixes the places that use desktop files to launch the executable, for example in LXDE menu. However, the file manager is still broken, I assume it goes directly to /usr/bin/firefox.
@RonCam commented on GitHub (Mar 9, 2016):
Just to make sure I'm understanding this discussion correctly -- is this summary correct?
By using a symbolic link, .desktop files will now run a sandboxed copy of Firefox -- from anywhere on the system, as well as from the Start Menu/Application Launcher (KDE terminology). Likewise, Session Restore will create a sandboxed copy of Firefox, whenever the system restarts.
The only time Firefox will start unsandboxed would be if one clicks directly on the executable in /usr/bin/firefox. 😆 I can live with that, very easily. That's not the usual way of starting a browser, anyway.
@chiraag-nataraj: Is this all working, without 'glitches', on your VM? If yes, then may I suggest this be documented as the default method for starting sandboxed programs? Once set up, it seems unlikely for the user to have 😟 moments, as I did when I suddenly realized Firefox had 'gotten out' of the box.
@chiraag-nataraj commented on GitHub (Mar 9, 2016):
@RonCam: I'm not quite sure because KDE refuses to play well with my VM 😝
@RonCam commented on GitHub (Mar 9, 2016):
@chiraag-nataraj: Not to worry, I'll go ahead tomorrow, as netblue30 recommends, and observe Firejail's behavior, especially checking how it continues to protect Firefox during logoffs, shut-downs and restarts.
When you depend on something to protect the system, it's nice to have reassurance it's always there -- and it hasn't disappeared without notice, due to some unexpected 'glitch'. With Sandboxie I would always look for the yellow highlight (its color was configurable) framing the sandboxed window, and then I would know nothing had gone awry.
@RonCam commented on GitHub (Mar 10, 2016):
@all following this thread, quoted from a previous post:
Would I be correct in assuming the answer to the question, in the first line -- is a 'Yes'?
That would be most helpful so I know exactly for what I should be looking, as I proceed.
I find that by restating, in one place, the 'bits' from posts of others who are better informed than I serves as a double-check to confirm I am following, without misunderstanding.
Thanks!
@netblue30 commented on GitHub (Mar 10, 2016):
@roncam - yes, your summary is correct.
@RonCam commented on GitHub (Mar 19, 2016):
There is a problem -- firefox can't find its profile.
I've edited the main start menu entry to remove firejail and have entered the suggested line at terminal to create a symbolic link. What's the best way of fixing this, so that firefox will run 'correctly' when started either by itself, or with firejail?
@RonCam commented on GitHub (Mar 26, 2016):
I've started a new thread.