mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #1594] Problem with private-tmp in okular and libreoffice profiles #1063
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#1063
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 @curiosity-seeker on GitHub (Oct 7, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1594
I cannot open attached documents in Thunderbird when
private-tmpis activated in okular.profile and libreoffice.profile, hence I addedignore private-tmpto my individual profiles. Note that I've set xdg-open as helper application for each file type.But am I really the only one affected by this? If not, this rule would break important functionalities for many users.
@Fred-Barclay commented on GitHub (Oct 7, 2017):
I can't duplicate this - using the default thunderbird profile, I can open files in libreoffice.
Are you using the default thunderbird profile and the latest firejail? The tbird profile has
ignore private-tmpalready.@smitsohu commented on GitHub (Oct 7, 2017):
Reproducible for me. Try with the following in okular.local
and replace curiosity-seeker with your actual user name
(paths edited)
@curiosity-seeker commented on GitHub (Oct 8, 2017):
@Fred-Barclay : Yes, I know that the tbird profile already cpntains that rule but the problem is with the okular and libreoffice profiles.
@smitsohu : Indeed, I'm getting an error that
/tmp/mozilla_user0/...doesn't exist. However,ignore private-tmpis sufficient for me in both profiles, the other two rules are not needed here.So the question is - as @Fred-Barclay couldn't reproduce - if the problem is widespread enough to justify commenting
private-tmpin both profiles.@smitsohu commented on GitHub (Oct 8, 2017):
@curiosity-seeker if codeblock works for you, it gets you as close as possible to what
private-tmpoffers security-wise, while still permitting what you intend to doA related side note: pdf reader evince has
private-tmpcommented out for compatibility with firefox since84230c5ed4, and the same was later added to its forks atril and xreader by analogy. Is this still relevant? In my hands the pdf readers always run inside the firefox sandbox, and if xdg-open doesn't add new justification to keepprivate-tmpcommented, I'd propose reenabling it across all pdf readersedit: also note that the firefox profile has a
private-tmpoption, which should prevent data exchange through the real /tmp directory@curiosity-seeker commented on GitHub (Oct 8, 2017):
@smitsohu
You mean including the 2 whitelist rules? Yes, it works for me. (I've taken care that it is above disable-common.inc as that one contains
noexec /tmp/.X11-unix). Nevertheless, the question remains what to do if many users are also affected. Default profiles should not break such things.Sorry, I'm a bit confused. Why do you propose reenabling
private-tmpfor all pdf readers when this setting breaks functionalities for, at least, okular ?@smitsohu commented on GitHub (Oct 8, 2017):
@curiosity-seeker it seems you overlooked the
part. In the end the question is to which degree we want to support xdg-open. I suppose this issue is not limited to thunderbird, there should be the same issue with firefox, too.
Btw, if noexec is important to you, don't forget to explicitly
noexec /tmp/mozilla_user0@curiosity-seeker commented on GitHub (Oct 8, 2017):
Ah, yes, sorry, I had overlooked that, indeed!
@curiosity-seeker commented on GitHub (Oct 8, 2017):
I've just tried again to not use xdg-open but set okular itself as the helper application for pdf files in Thunderbird. Result: above codeblock is not needed - but okular now runs as as a child process of the firejailed thunderbird (which it does not if xdg-open is used - okular is running as its own firejailed process).
So what's preferable security-wise?
When running as a child process it has full access to ~/.thunderbird. I'm not sure that I want that. As a general rule I don't like running helper applications as child processes as this undermines the security provided by the respective fine-tuned profiles for them.
BTW: I also don't use the default thunderbird.profile as it includes firefox.profile. In other words, Thunderbird has full access to ~/.mozilla. This is unfortunate, IMHO.
@Fred-Barclay commented on GitHub (Oct 8, 2017):
@curiosity-seeker
Ah - that's what I was missing. I didn't know xdg-open spawned programs into a separate sandbox, hence my thinking that the
ignore private-tmpin thunderbird's profile was enough. 😄@curiosity-seeker commented on GitHub (Oct 8, 2017):
Fred, yes, that's an important difference, IMO. I remember that I've read here in other issues that using xdg-open is a possible security threat. Sure, that's not completely ruled out if another (malicious?) application changes the defaults to un-sandboxed (and possibly malicious) applications. But I wonder how big that risk really is - I consider it very small.
A bigger risk, IMO, is that - as I wrote above - a helper application running as a child process can manipulate, e.g., my Thunderbird or Firefox profiles if it opens malicious data. If it were running in its own process tightly confined by its profile this would hardly be possible - but now it is. That's why I prefer the xdg-open variant as the risk is smaller.
That's just my 2 cents. Implementing this philosophy would require changes in several profiles as exemplarily discussed above. And we would have to convince Firejail users somehow to use xdg-open in, e.g., Thunderbird.
@Fred-Barclay commented on GitHub (Oct 8, 2017):
I see. And the (potential) issue with xdg-open if I'm understanding it correctly is that it seems to require a shell, grep, and egrep for any use, as well as other utilities for specialised use. We'd have to add those to all private-bin filters.
@smitsohu commented on GitHub (Oct 8, 2017):
@Fred-Barclay yes, and we probably have to disable
private-tmpin some places, or keep it disabled.But a general question: Is it possible the issues with
private-tmpexist only on KDE? I remember I have seen it on KDE, but just noted that I have trouble reproducing it on Mate.@smitsohu commented on GitHub (Oct 9, 2017):
@curiosity-seeker I believe xdg-open delegates work to KIO on KDE (via kde-open). If that's right, it is the reason why Okular is launched outside the sandbox (see #1599), where in your case it is again confined by Firejail, now with a tailored profile.
In a way that's nice, because the most dangerous part about email is attachments, and the default Okular profile denies internet access, access to emails, browser profiles... But at the bottom I think it is a security flaw itself.
In the context of xdg-open, I didn't see sandbox escapes outside KDE (please correct me). This means that also issues with
private-tmpshould be limited to xdg-open on KDE, and further the helper application must be set to run in Firejail automatically.@curiosity-seeker commented on GitHub (Oct 13, 2017):
@smitsohu : Thanks for your comments and your commit! Unfortunately I'm on a trip abroad and cannot test it - but I will certainly when I'm back.
@smitsohu commented on GitHub (Oct 15, 2017):
@curiosity-seeker yes, please try it out when you have time :)
@curiosity-seeker commented on GitHub (Oct 20, 2017):
@smitsohu : I must admit that I'm a bit confused and I'm not sure what to make of all this. As I wrote in #1599 there is no sandbox escape of okular for me.
Regarding helper applications in Thunderbird your commit doesn't change the behavior mentioned above: if okular or libreoffice are started via xdg-open they are launched in their own firejailed processes, otherwise they are launched as sub-processes of Thunderbird. The latter is a security risk and I don't want that.
Hm - why exactly? As long as there is no private-bin line in the (Thunderbird) profile, everything in, e.g., /usr/bin can be executed including xdg-open. Does this really qualify as a sandbox escape?
I can't comment on that as I'm a die-hard KDE user. What is the exact behavior in Gnome if you set xdg-open and, alternatively, Evince as helper applications in Thunderbird?
@smitsohu commented on GitHub (Oct 20, 2017):
Can you try starting Thunderbird with
--blacklist /run/user/$UID/bus, and then open a pdf attachment through xdg-open? This with Firejail from git.There shouldn't be an escape... if Okular still escapes, our picture is not complete yet.
@curiosity-seeker commented on GitHub (Oct 20, 2017):
Okay, I added
blacklist /run/user/$UID/busto my Thunderbird profile.With the symlink for okular it starts as its own firejailed process.
Without the symlink it starts unsandboxed.
@smitsohu commented on GitHub (Oct 20, 2017):
Hmmm.
In case you pasted
blacklist /run/user/$UID/bus, could I ask you to try again withblacklist /run/user/1000/bus? Sorry for the trouble.@curiosity-seeker commented on GitHub (Oct 20, 2017):
I did that and in both cases (with and without the symlink) okular starts as a sub-process of the firejailed Thunderbird. Interesting! But it's not what I prefer.
@curiosity-seeker commented on GitHub (Oct 21, 2017):
To me this discussion leads to 2 questions:
@smitsohu commented on GitHub (Oct 24, 2017):
@curiosity-seeker you are doing it right IMO. Attachments are the dangerous thing, so it makes sense to loosen a bit the sandbox of the email client (permit D-Bus), if the helper application runs then in a much tighter sandbox.
I would think twice before doing the same with a browser though.
I tried with Gnome, Mate, Cinnamon, Xfce. It seems to be a KDE peculiarity.
from #1386, adding something like
xdg-open,sh,grep,egrep,kde-open*to private-bin should help. Adding the helper application itself is not necessary as long as there is D-Bus.But back to the original issue: In light of all of this, what do we do with private-tmp? Currently we support use cases like yours for some pdf readers, but maybe we should do it only for Okular (as the KDE default)? Or we add Okular to the list to have more or less all stock readers covered? I would hesitate to remove private-tmp beyond this, but I'm curious if there are other opinions.
@Vincent43 commented on GitHub (Oct 24, 2017):
In my opinion it's best to move
TMPDIRinside user$HOME, i.e.~/.cache/tmpby settingTMPDIR=environment variable and add this directory to global whitelist while leavingprivate-tmpuntouched. It somewhat middle-ground as It's more secure than having system wideTMPDIRand it doesn't cause breakages when two applications want to share the same temporary file.@curiosity-seeker commented on GitHub (Oct 25, 2017):
@smitsohu : I'm glad that you agree.
How is the behavior if you set Evince as the helper application in Thunderbird? Does it also execute as a sub-process like Okular?
Any opinion about @Vincent43 's suggestion?
@Vincent43 commented on GitHub (Oct 25, 2017):
To be clear, my suggestion is about local system configuration. Nothing to do on firejail side except rationale for keeping
private-tmpenabled in profiles.@smitsohu commented on GitHub (Oct 25, 2017):
@Vincent43 thanks for your suggestion! It is actually possible to do everything in firejail... add to thunderbird.local:
and
whitelist ~/.cache/tmpto /etc/firejail/whitelist-common.local, and you're set to bring backprivate-tmpto thunderbird and your pdf-reader.Part of the feature description, but still noteworthy: Opened attachments are then visible to more or less all concurrently running (firejailed or not) processes. Also, if thunderbird crashes, /tmp is tidied upon reboot, whereas ~/.cache/tmp is not.
@curiosity-seeker Yes, evince ends up in the same sandbox as thunderbird, not in its own.
@smitsohu commented on GitHub (Oct 26, 2017):
It would be possible to take it one step further and blacklist/noblacklist ~/.cache/tmp.
If we added noblacklist only to the pdf reader profiles, we reached today's level of xdg-open support... and could bring back private-tmp in several places :)
What about having in thunderbird.profile something like:
@curiosity-seeker commented on GitHub (Oct 26, 2017):
@smitsohu : Unfortunately this does not work for me. I added those two lines to my Thunderbird profile and `noblacklist ~/.cache/tmp to the Okular profile (although this should not be necessary as that folder is not blacklisted in any *.inc file) but I got an error in Okular:
Could not open file:///home/hank/cache/tmp/...Perhaps I'm missing something trivial ... ?
EDIT: I had forgotten to add
whitelist ~/.cache/tmpto my Thunderbird profile (as it's a whitelisted profile). It works now as expected! I will further investigate.EDIT2: I can confirm that Okular works even after re-enabling
private-tmpin its profile.EDIT3: It also works for LibreOffice after adding
whitelist ~/.cache/tmpto my tightened whitelisted profile (and re-enablingprivate-tmp). In the default libreoffice.profilenoblacklist ~/.cache/tmpshould work.@Vincent43 commented on GitHub (Oct 26, 2017):
You can also add
whitelist ~/.cache/tmpto/etc/firejail/whitelist-common.localinstead of adding it to each profile and assuming that you includewhitelist-common.incin your profiles.The same you can add
env TMPDIR=/home/username/.cache/tmpto/etc/firejail/globals.local.@curiosity-seeker commented on GitHub (Oct 26, 2017):
Yes, but this works only for whitelisted profiles. For example, default libreoffice.profile is not a whitelisted profile, hence whitelist-common.local cannot be used.
I don't think that I want that as I prefer to restrict access for specific applications only. I rather add
blacklist ~/.cache/tmpto globals.local and add noblacklist or whitelist rules whereever needed.@curiosity-seeker commented on GitHub (Oct 27, 2017):
Hm - whenever I add
TMPDIR=~/.cache/tmpto the Thunderbird profile, HTML emails are no longer displayed. Any idea why?@Vincent43 commented on GitHub (Oct 27, 2017):
Works for me. What's your
thunderbird.profile?@curiosity-seeker commented on GitHub (Oct 27, 2017):
Voilà:
@Vincent43 commented on GitHub (Oct 27, 2017):
I tried your config and HTML emails are displayed correctly. Maybe it's thunderbird config issue, you can try with fresh profile.
@curiosity-seeker commented on GitHub (Oct 28, 2017):
@Vincent43 : You're right, it works for me,too. I made a silly mistake, sorry :-(
So - should this issue be closed? It's fixed for me but I don't know if it should be kept open in order to possibly adjust specific profiles accordingly.
@smitsohu commented on GitHub (Oct 28, 2017):
Ok, maybe we fix it conservatively for now, add a comment to thunderbird and disable private-tmp in okular?
Feeling is rather that
private-tmpcan go back to all other pdf readers... xdg-open is broken in firefox already since quite some time because of theprivate-tmpthere.@curiosity-seeker commented on GitHub (Oct 28, 2017):
Yes, I think that's a good proposal. Just don't forget to add
whitelist ~/.cache/tmpto that comment as the Thunderbird profile is a whitelisted profile.I'm not sure that I understand. Firefox with private-tmp is properly launched via xdg-open here.
@smitsohu commented on GitHub (Oct 28, 2017):
The same issue that you had with thunderbird exists with firefox. Also there you can use xdg-open to handle pdfs, ...
@curiosity-seeker commented on GitHub (Oct 28, 2017):
Ah, yes, I see. I didn't think of this as pdf files are usually opened in the built-in pdf reader. But if it comes to, e.g., doc files (-> libreoffice) this is relevant, indeed.
@curiosity-seeker commented on GitHub (Nov 6, 2017):
I've noticed only now that when using above profile - i.e. with
env TMPDIR=~/.cache/tmp- print preview and accessing my printer is broken in Thunderbird. Commenting this rule solves the problem.@Vincent43 commented on GitHub (Nov 6, 2017):
Try with absolute path:
env TMPDIR=/home/curiosity-seeker/.cache/tmp@curiosity-seeker commented on GitHub (Nov 7, 2017):
Wow - that change solved the problem, indeed! I didn't expect that. Do you have an explanation?
@Vincent43 commented on GitHub (Nov 7, 2017):
Non-absolute env variables aren't properly resolved, i.e.
env TMPDIR=~/.cache/tmpgives you literallyTMPDIR=~/.cache/tmpinstead ofTMPDIR=/home/username/.cache/tmpwhich is garbage.You can test it yourself:
@curiosity-seeker commented on GitHub (Nov 7, 2017):
Indeed, I can reproduce what you're saying. Thanks for this info - I learned soemthing new today!
@curiosity-seeker commented on GitHub (Dec 17, 2017):
After coming back from a trip I noticed that the solution above does not work any more.
My Thunderbird profile contains the following rules:
When I try to open a pdf attachment with Okular I get an error that
file:///tmp/mozilla_curiosity-seeker0/Example.pdfcould not be opened.And after disabling private-tmp I can open the pdf and firejail --list reports:
/usr/bin/firejail /usr/bin/okular /tmp/mozilla_curiosity-seeker0/Example.pdfIt seems that the env variable is no longer applied - but it used to work earlier. Is perhaps
envbroken due to a recent change?@Vincent43 commented on GitHub (Dec 17, 2017):
Yeah, it seems firejail doesn't pass TMPDIR env variable.
Opened issue: https://github.com/netblue30/firejail/issues/1682
@Vincent43 commented on GitHub (Dec 18, 2017):
@curiosity-seeker can you confirm that you can reproduce below on https://github.com/netblue30/firejail/issues/1682
@curiosity-seeker commented on GitHub (Dec 18, 2017):
@Vincent43 : Yes, I can reproduce!
norootseems to be the culprit, indeed.