Securing Obsidian - Boxes and Walls
So, you've installed a malicious plugin? What can it do anyway? Well, it could simply extract some data from you, or anything from A to Z. These plugins have access to nearly your whole system.
I don't like that plan, so I've done something about. In the following, I'll attempt to walk you through your options in as least technical way I can.
Additionally, if you haven't read my first post in my "Securing Obsidian" series, I highly suggest you check it out here. At minimum, I advise reading the 'Threat Modeling' section before proceeding.
The Problem
For desktop operating systems, applications tend to have far too many privileges. This problem is only exacerbated by Obsidian's thirst for unchecked third-party content.
Now, luckily, mobile operating systems are stricter, but they can pose a risk.
Obsidian needs to know its place. It has no need for the ability to log you out of your computer, yet I have a plugin that does[1]. And trust me, logging you out of your computer is the least of your worries.
Firewalls
The most frequent threat we face is spyware, trackers, etc. Not that I'm in support of these data hungry companies, but I'm more concerned about the wasted resources than actually being tracking.
Luckily, we have a couple great solutions:
1. ) Don't install them.
2. ) Block their "callback" domains.
This is where an outbound firewall comes in to play. Specially a WAF[2], and, more important, one that can create a whitelist on a per program/process basis and filter based on domain name opposed to IP address. This would allow me to block Google from loading within Obsidian but not within my browser.
(If nothing else, a WAF works great for blocking advertisements)
Desktop Options:
- Portmaster (Windows 7-11, GNU/Linux)
- A promising newcomer. Previously, Windows didn't have any good options. Not to mention that it's open-source. (Tutorial)
- Little Snitch (MacOS)
- The classic option for Mac users. Although premium and closed-source, it's considered a trusted project.
- Objective-See's LuLu (MacOS)
- An open-source alternative to Little Snitch developed by former NSA hacker, Patrick Wardle. If I was a MacOS user, this would be my choice. (An overview by Hands-On Mac)
- Open Snitch (GNU/Linux)
- An open-source port of Little Snitch to GNU/Linux. Personally I prefer Portmaster, but this is a great alternative. (Tutorial)
Mobile Option...
Yes, unfortunately, mobile isn't endowed in the WAF department.
For Android users, Netguard is a great open-source option. It uses the built-in VPN service of Android, but does not connect to an actual VPN server. In other words, it's not an actual VPN. It just leverages the functionality. (Tutorial)
For IOS users, I am not aware of any real options. Lockdown Privacy is the closest I've seen. It's open-source, but has no option for a whitelist on an application basis. It'll block known malicious domains and any of your choosing, but fails to alert of any unknown domains. Not unlike Netguard, this app uses the VPN service of IOS.
Additionally, this app offers a paid VPN tunnel (not to be confused with the "VPN service of IOS"). I do not condone this VPN. I merely use the app for the WAF functionality.
Surviving The Process
Once you setup an outbound firewall, Obsidian may break in one way or another.
In general, you should only allow requests you know to be relevant. This takes some time to get used to. Domain names have no logic in them, but over time, you'll get a feel for what domain provides what.
For instance, to watch a YouTube video, you'll need to allow www.youtube.com, .i.ytimg.com, and *.googlevideo.com, but you don't need to allow www.gstatic.com or any of the others.
Trial and error is your friend. Don't overthink it and disable everything. If you're not sure, just enable it. You can always go back to change it later.
Additionally, poorly made scripts or plugins may freeze when their request gets blocked. In this case, your Vault may stop responding. This should resolve itself after allowing the request. If it still doesn't work after allowing it, try restarting Obsidian.
Certain content may spam requests to slightly different subdomains. For instance, if you load a YouTube video, you may see a bunch of domains ending in .googlevideo.com. Instead of allowing each one, I suggest adding a "wildcard". In this case, that would be *.googlevideo.com. This syntax simply treats the asterisk (*) as any valid character/s. Whether that be a.contrived.example.googlevideo.com or f-r-a-n-k.googlevideo.com, all the domains ending in .googlevideo.com will be allowed.
Sandboxes
Whereas a WAF is generally useful, sandboxes are quite specific. They are best used to mitigate the effects of a malware attack. Or, at least, a dumb one.
Sandboxes are not perfect, a dedicated attack can break them. But we're not here to stop those attackers. After all, if an APT[3] wants to "hack" me, I couldn't do a thing to stop them. The goal here is simple: don't let the dumb malware steal or encrypt files that could've otherwise been protected.
Windows
Sandboxie is an open-source partially premium "application virtualization" solution; however, The lack of proper file-system controls is damning, so it's unfortunate it's the only real option for Windows. (Tutorial)
MacOS
Mac takes care of itself... kinda. All applications from the App Store are required to define their permissions properly...
Obsidian is not available from the App Store[4], so the precautions taken from the developers are not entirely known, but they are not very strict.
That said, MacOS has the sandbox-exec command which allows users to define their own permissions for any give application. Sadly, this function is to be depreciated. The functionality still currently available, so if you want to collaborate to create a configuration, let me know (Twitter @ohm_uni).
GNU/Linux
Linux has a lot of options, but they use a lot of the same underlying technologies (namespaces, etc).
Additionally, X11 applications commonly used on Linux are insecure. Solutions like Wayland and Zephyr are available, but beyond the scope of this article. (A tutorial for Zephyr is shown in the FireJail tutorial.)
- FireJail
- My preferred way to sandbox applications. Currently, no profile for Obsidian exists, but has been requested. For now, you can follow my tutorial here.
- Flatpak (aka Bubblewrap)
- 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.
- Snap
- A comparable alternative to FlatPak, but is maintained by the Obsidian developers. (The download can be found here.)
(Programs like Firejail and Bubblewrap are SUID binaries which can allow for accidental privilege escalation. Make sure these programs remain up to date!)
Mobile
You don't have options with mobile platforms like Android and IOS. They do it for you, so rejoice! Just remember, rooting on Android or Jailbreaking IOS breaks this security. I advise against it unless you know what you're doing[5].
Also, if your running Android, you can utilize a "Work Profile" for an additionally layer of separation. This open-source application, Shelter, does a great job at leveraging this feature.
Further Considerations
You want more? More security? All that, and your not satisfied?? Okay, we can do much better.
Your next step may be to use a VM (Virtual Machine), but we can go a bit further. However, that's for another time. Exploring these ideas is beyond the scope of this article.
Maybe in the future I'll show how to use Obsidian inside Firejail with AppArmor inside of a Docker container inside of a VM inside of another Docker container?!
To be honest, with all the added complexity, we may end up less secure. It's really hard to tell with these things. But, it's a fun idea, isn't it?