Hello, after seeing this post on the security of plugins, I figured to do my part in educating users about security.
What are our actual concerns with third-party content? I suppose it’s just that we can’t trust them to use their privilege responsibly?
When it comes to impact, what’s your biggest concern? Personally, ransomware would be of most concern, but, with my setup, hopefully such a “hacker” would fail.
Great articles, especially the one about boxes and walls.
In my case, I am not that concerned about my notes security, but, I am very concerned about the possibility of plugin escalate privileges and have access to SSH keys, Google Chrome password, and project source code.
My first idea was to use Docker as a sandbox to run the Obsidian, you only mention it at the end of the article as a kind of exaggeration joke. I would love to hear more from you how would you set up it on Docker if ever done that.
Hey @meaningfuel,
I’ve been behind on things (life), so please excuse my delay.
In short, yes, Docker is possible, but only on Linux from my understanding. I will consider setting it up and writing about my finding.
But something you can do immediately (if you’re on Linux) would be to install the Flatpak. It’s not the best option, but does have a form of storage scopes which would likely protect your SSH keys.
Thank you
P.S.
Feel free to message me if you want to get into specifics. I’ll be doing my best to keeping up with replying.
The Obsidian flatpak’s README has examples on tuning sandbox permissions:
@jstone thank you.
That shouldn’t have slipped past me yet it did, so I really appreciate you bringing that to my attention. I’ll keep this in mind when updating my article.
I look forward to reading the updated article!
Since Obsidian is supported, this is the easiest way to sandbox your Vaults on Linux. However, I’ve found this option to be far less secure than FireJail.
I do feel there is a bit of nuance with regard to Flatpak’s sandboxing, because while it may be less “powerful” than Firejail, it’s quite simple to configure on the command line with minimal permissions, and there a graphical frontends like Flatseal and KDE’s flatpak KCM.
The default permissions are set up mostly for convenience due to the sheer number of plugins that aren’t designed for running in a sandboxed environment, but they still can be managed for those who’re inclined to audit permissions.
I personally run Obsidian with very few plugins, so I can disable almost all permissions and force it to run on Wayland only:
$ flatpak info --show-permissions md.obsidian.Obsidian
[Context]
sockets=wayland;
devices=dri;
filesystems=
persistent=~/.ssh;
[Session Bus Policy]
org.freedesktop.portal.Fcitx=talk
[Environment]
SSH_ASKPASS=/app/libexec/openssh/ssh-askpass
OBSIDIAN_ENABLE_AUTOSCROLL=0
PATH=/usr/bin:/app/bin:/app/texlive/bin:/app/texlive/bin/x86_64-linux:/app/texlive/bin/aarch64-linux
OBSIDIAN_DISABLE_GPU=0
GH_PATH=gh
OBSIDIAN_USE_WAYLAND=1
XCURSOR_PATH=/run/host/user-share/icons:/run/host/share/icons
OBSIDIAN_DISABLE_GPU_SANDBOX=0
$ flatpak override --user --show md.obsidian.Obsidian
[Context]
filesystems=!home;!/media;!/run/media;!/mnt;!xdg-run/app/com.discordapp.Discord;
shared=!network;!ipc;
sockets=!x11;!pulseaudio;!ssh-auth;
[Environment]
OBSIDIAN_USE_WAYLAND=1
It seems like flatpak is more convenient than I thought. I’ve only used them when really needed in the past, but it looks really powerful.
I appreciate the reference. I’ll certainly look more into this before updating the article. Thank you.