3 ms·

>I think the best (only?) way to solve the plugin security problem would be to properly sandbox them with an explicit API and permission system. I want to say

by andai 6mo ago

>I think the best (only?) way to solve the plugin security problem would be to properly sandbox them with an explicit API and permission system. I want to say "and especially prevent them from touching my private data (i.e. the whole point of Obsidian plugins being to read/write the documents)". But if it can't talk to the internet, I kind of don't see the issue. EDIT: Apparently due to how JS and Electron works, Obsidian plugins are just JS blobs that run in the global scope, and can read/write the whole filesystem (limited by user permissions) and make HTTP requests? Can someone confirm/deny this pls?

Groxx 6mo ago
Confirmed: https://obsidian.md/help/plugin-security#Plugin+capabilities https://obsidian.md/help/plugin-security#Plugin+capabilities There is no sandboxing at all. Every plugin has full access to your computer.
- thinkling 6mo ago
  Is there auto-updating of plug-ins? Installing a plug-in and reviewing its code at that point is one thing. But if the plug-in can be updated withut you knowing, then there’s little guarantee of security.
  - kepano 6mo ago
    You can automatically check for updates but it's off by default, and still requires a manual click. Also the new plugin review system automatically scans every release.
- gitgud 6mo ago
  Well damn, start the countdown till the inevitable exploit of this. I’m thinking maybe 1 or 2 weeks from now…
tomjakubowski 6mo ago
Theoretically in an Electron app, you could run plugins in a separate v8 context without the node native FS libraries available. Short of OS-level sandboxing that's probably the best they could do.
- darthwalsh 6mo ago
  Like what cloudflare does in EmDash (the spiritual successor to WordPress). But almost all plugins would need to be rewritten?
nickjj 6mo ago
> But if it can't talk to the internet, I kind of don't see the issue. No internet access doesn't save you. With file system access it can delete a file. Without sudo access it can silently add something to your user's crontab so a few days from now it runs a custom shell script that does anything with internet access. If you're not checking into this sort of thing regularly, you wouldn't know. It can add something to your user's shell's rc so when you open a new terminal session, a bad side effect happens. Malware scanning won't protect from these sort of things and every time a new version is available, it's another opportunity for something bad to happen. To be fair this isn't a problem unique to Obsidian. Code editor plugins and most programming language package managers have the same problem.
- andai 6mo ago
  Oh right. I keep forgetting second order effects are a thing.
- antiframe 6mo ago
  > To be fair this isn't a problem unique to Obsidian. Code editor plugins and most programming language package managers have the same problem. While it's not unique to Obsidian, Obsidian not being open source makes it harder to verify their security model. Personally I use a note taking system which has the same problem but all the code I run is visible to me and I can scan it myself.
uncSoft 6mo ago
That's why I wrote cyberwriter, my company needs sandboxed apps because we work on sensitive data. Community plugins are too risky running with full system access

by andai 6mo ago

Groxx 6mo ago

Confirmed: https://obsidian.md/help/plugin-security#Plugin+capabilities https://obsidian.md/help/plugin-security#Plugin+capabilities There is no sandboxing at all. Every plugin has full access to your computer.

thinkling 6mo ago
Is there auto-updating of plug-ins? Installing a plug-in and reviewing its code at that point is one thing. But if the plug-in can be updated withut you knowing, then there’s little guarantee of security.
- kepano 6mo ago
  You can automatically check for updates but it's off by default, and still requires a manual click. Also the new plugin review system automatically scans every release.
gitgud 6mo ago
Well damn, start the countdown till the inevitable exploit of this. I’m thinking maybe 1 or 2 weeks from now…

tomjakubowski 6mo ago

Theoretically in an Electron app, you could run plugins in a separate v8 context without the node native FS libraries available. Short of OS-level sandboxing that's probably the best they could do.

darthwalsh 6mo ago
Like what cloudflare does in EmDash (the spiritual successor to WordPress). But almost all plugins would need to be rewritten?

nickjj 6mo ago

> But if it can't talk to the internet, I kind of don't see the issue. No internet access doesn't save you. With file system access it can delete a file. Without sudo access it can silently add something to your user's crontab so a few days from now it runs a custom shell script that does anything with internet access. If you're not checking into this sort of thing regularly, you wouldn't know. It can add something to your user's shell's rc so when you open a new terminal session, a bad side effect happens. Malware scanning won't protect from these sort of things and every time a new version is available, it's another opportunity for something bad to happen. To be fair this isn't a problem unique to Obsidian. Code editor plugins and most programming language package managers have the same problem.

andai 6mo ago
Oh right. I keep forgetting second order effects are a thing.
antiframe 6mo ago
> To be fair this isn't a problem unique to Obsidian. Code editor plugins and most programming language package managers have the same problem. While it's not unique to Obsidian, Obsidian not being open source makes it harder to verify their security model. Personally I use a note taking system which has the same problem but all the code I run is visible to me and I can scan it myself.

uncSoft 6mo ago

That's why I wrote cyberwriter, my company needs sandboxed apps because we work on sensitive data. Community plugins are too risky running with full system access