Less is safer: How Obsidian reduces the risk of supply chain attacks

Obsidian has a truly terrible security model for plugins. As I realized while building my own, Obsidian plugins have full, unrestricted access to all files in the vault.

Obsidian could've instead opted to be more 'batteries-included', at the cost of more development effort, but instead leaves this to the community, which in turn increases the attack surface significantly.

Or it could have a browser extension like manifest that declares all permissions used by the plugin, where attempting to access a permission that's not granted gets blocked.

Both of these approaches would've led to more real security to end users than "we have few third party dependencies".

https://www.youtube.com/watch?v=eU2Or5rCN_Y

And how exactly you can solve that?

I don't want to press 'allow access' on the every file some plugin is accessing.

IMO they should do something like aur on Arch Linux and have a community managed plugin repo and then a smaller, more vetted one. That would help with the plugin review time too.

If they wanted to, one would guess that browser-ish local apps based on stuff like Electron/node-webkit could probably figure out some way to limit extension permissions more granularly.

There is no reason for pdf.js to ever access anything other than the files you wish to export. The Export to PDF process could spawn a containerized subprocess with 0 filesystem or network access and constrained cpu and memory limits. Files could sent to the Export process over stdin, and the resulting PDF could be streamed back over stdout with stderr used for logging.

There are lots of plugin systems that work this way. I wish it were commodofied and universally available. AFAIK there's very little cross-platform tooling to help you solve this problem easily, and that's a pity.

FWIW, MacOS isn't any better or worse for security than any other desktop OS tbh....

I mean, MacOS just had it's "UAC" rollout not that long ago... and not sure about you, but I've encountered many times where someone had to hang up a Zoom or browser call because they updated the app or OS, and had to re-grant screenshare permissions or something. So, not that different. (Pre-"UAC" versions of MacOS didn't do any sandboxing when it came to user files / device access)

I would say VSCode has no excuse. It's based on a browser which does have capabilities to limit extensions. Huge miss on their part, and one that I wish drew more ire.

Sneak in a malicious browser extension that breaks the permissions sandbox, and you have hundreds of thousands to millions of users as an attack surface.

Make a malicious VSCode/IDE extension and maybe you hit some hundreds or thousands of devs, a couple of smaller companies, and probably can get on some infosec blogs...

Do you mean mods on Steam? If you do, then that's down to the individual game. Sandboxing mods isn't universal.

If engineers can't even manage their own security, why are we expecting users to do so?

This latest attack hit Crowdstrike as well. Imagine they had gotten inside Huntress, who opened up about how much they can abuse the access given: https://news.ycombinator.com/item?id=45183589

Security folks and companies think they are important. The C suite sees them as a scape goat WHEN the shit hits the fan and most end users feel the same about security as they do about taking off their shoes at the airport (what is this nonsense for) and they mostly arent wrong.

It's not that engineers cant take care of their own security. It's that we have made it a fight with an octopus rather than something that is seamless and second nature. Furthermore security and privacy go hand and hand... Teaching users that is not to the benefit of a large portion of our industry.

I dunno. My computer has at least 1 hardware backdoor that I know off, but that I just can't get hardware without any equivalent exploit.

My OS is developed with a set of tools that is known to make code revision about as hard as possible. Provides the bare minimum application insulation. And is 2 orders of magnitude larger than any single person can read on their lifetime. It's also the usable OS out there with best security guarantees, everything else is much worse or useless.

A browser is almost a new complete layer above the OS. And it's 10 times larger. Also written in a way that famously makes revisions impossible.

And then there are the applications, that is what everybody is focusing today. Keeping them secure is close to useless if one don't fix all of the above.

Unless something has changed, it's worse than that. Plugins have unrestricted access to any file on your machine.

When I brought this up in discord a while back they brushed it aside.

One thing that makes our offering unique is the ability to self-host your Relay Server so that your docs are completely private (we can't read them). At the same time you can use our global identity system / control plane to collaborate with anyone in the world.

We have pretty solid growth, a healthy paid consumer base (a lot of students and D&D/TTRPG), and starting to get more traction with businesses and enterprise.

[0] https://relay.md

But I haven't heard anyone talk like that in quite sometime (unless it's me parroting them). Which is quite unfortunate.

I think for example if someone from the old guard of Blizzard were to write a book or at least a novella that described how the plugin system for World of Warcraft functioned, particularly during the first ten years, where it broke, how they hardened it over time, and how the process worked of backporting features from plugins into the core library...

I think that would be a substantial net benefit to the greater software community.

Far too many ecosystems make ham-fisted, half-assed, hair-brained plugin systems. And the vast majority can be consistently described by at least two of the three.

It sounds like if I ever run obsidian I should be using flat seal too.

It's pretty much the opposite. A lot of modding communities' security model is literally just to "trust the community."

Example: https://skylines.paradoxwikis.com/Modding_API

> The code in Mods for Cities: Skylines is not executed in a sandbox.

> While we trust the gaming community to know how to behave and not upload malicious mods that will intentionally cause damage to users, what is uploaded on the Workshop cannot be controlled.

> Like with any files acquired from the internet, caution is recommended when something looks very suspicious.

I'm not claiming it's a security feature of Obsidian, I'm saying it's a consequence of running a flatpak - and in this situation it could be advantageous for those interested.

The derivatives are obviously completely separate from Arch and thus are not the responsibility of Arch maintainers.

The lessons from all fields seem to be relearnt again and again in new fields :-)

The Emily language (locked-down subset of OCaml) was also interesting for actively removing parts of the standard library to get rid of the escape hatches that would enable bypassing the controls.

It might be slightly sped up by reading up on theory and past experiences of others.

I am around mid life and I see how I can tell people stuff, I can point people to resources but they still won’t learn until they hit the problem themselves and put their mind into figuring it out.

Seems a little excessive, but here we are.

It’s still the same problem, relying on the community and trusted popular plugin developers to maintain their own security effectively.

There are so many options, from so many different security perspectives, that analysis paralysis is a real issue.

And in general, it will take less hardware resources that the usual Electron stuff.

It might not be the most strategic move, but i want to build cool and useful tools, and the Obsidian folks are a big inspiration.

I hope there's a way to collaborate and/or coexist.

yay or paru (or other aur helpers afaik) are not in the repos. To install them one needs to know about how to use AUR in the first place. If you are technically enough to do that, you should know about the security risks since almost all tutorials for AUR come with the security warnings. Its also inconvenient enough that most people wont bother.

In obsidian plugins can seem central to the experience so users might not think much of installing them, in Arch AUR is very much a non essential component. At least thats how I understand it.

While somewhat true, we are talking about a user who has installed Arch on their machine. If a user wanted to not bother with installation details, they would've installed Ubuntu.

Is this true? Is there any source about how many obsidian users use third party plugins? For once I don't. Moreover, obsidian by default runs in "restricted mode" which does not allow for community plugins. You have to specifically enable it to be able to install community plugins, hence I assume somebody who does that understands the risks involved. How many people even get into enabling that?

For me it is not even about security firstmost, the whole appeal of markdown is simplicity and interoperability. The more I depend on "plugins" the more I am locked in into this specific platform.

Attackers just have to hit one dev with commit rights to an app or library that gets distributed to millions of users. Devs are multipliers.

Ah, the WordPress model.

I can't even install Brave without the AUR.

I got lazy

Time to crank the paranoidmeter up again

ty

For user-space, there is usually bubblewrap vs. firejail. I have not personally used bubblewrap, so I cannot comment on that, but firejail is great at what it does.

The last comment was about restricting clipboard access to either X11 or Wayland which is possible with firejail quite easily, so if you want that, you can have that.

You can do a LOT more with firejail though.

https://wiki.archlinux.org/title/Firejail

https://man.archlinux.org/man/firejail.1

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Yeah and they suck now. We need a better security model where it's still possible to do powerful stuff on the whole machine (it's MY computer after all) without compromises.

Eio is an IO library out of many competing ones, not OCaml's effect system. The capabilities are an Eio thing, not an effects thing.

At the end of the day, you're just taking notes. If you write a journal, don't put it in something like Obsidian. Even Apple Notes is better (in security, privacy, etc) in this regards.

I guess the intent behind Cities Skylines's support for mods is just removing the need for a mod manager and enabling Steam Workshop support.

Obviously it can detect malware if there’s a connection to some weird site, but it’s more like a bonus than a reliable test.

If you need to block FS access, then per app containers or VMs are the way to go. The container/VM sandboxes your files, and Little Snitch can then manage externa connectivity (you might still want to allow connection to some legit domains—-but maybe not github.com as that can be use to upload your data. I meant something like updates.someapp.com)

[1] https://docs.docker.com/desktop/settings-and-maintenance/set...

This is my ~/.config/firejail/Discord.profile[1]:

  include disable-common.inc
  include disable-devel.inc
  include disable-interpreters.inc
  include disable-shell.inc

  noblacklist /sys/fs
  noblacklist /sys/module

  keep-config-pulse
  keep-dev-shm

  name discord
  apparmor
  caps.drop all
  caps.keep sys_admin,sys_chroot
  netfilter
  nodvd
  #nogroups
  #noinput
  nonewprivs
  noroot
  notv
  #nou2f
  #novideo
  protocol unix,inet,inet6
  #shell none

  disable-mnt
  private-cache
  #private-tmp

  noexec /tmp

  dbus-user filter
  dbus-user.talk org.freedesktop.Notifications

  private-bin Discord,cut,echo,egrep,electron,electron[0-9],electron[0-9][0-9],grep,head,sed,sh,tr,xdg-mime,xdg-open,zsh,gzip,wget,curl,notify-send
  private-etc alternatives,asound.conf,ca-certificates,crypto-policies,fonts,group,ld.so.cache,ld.so.preload,localtime,login.defs,machine-id,password,pki,pulse,resolv.conf,ssl

  noblacklist /usr/lib/discord/
  whitelist ${HOME}/.config/discord
  read-write ${HOME}/.config/discord
  whitelist ${DOWNLOADS}
  whitelist ${HOME}/.config/pulse/*

  include whitelist-common.inc
  include whitelist-var-common.inc
  include whitelist-run-common.inc
  include whitelist-runuser-common.inc

Some has this, too:

  disable-mnt
  private-dev
  private-cache

  env http_proxy=socks5://127.0.0.1:9050
  env https_proxy=socks5://127.0.0.1:9050

You should check out the default profiles for many programs / apps under directory "/etc/firejail".

[1] You run it via "firejail Discord" or "firejail ./Discord" if you name it "Discord.profile".