Most active commenters
  • 0cf8612b2e1e(3)

←back to thread

429 points saeedesmaili | 19 comments | | HN request time: 0.732s | source | bottom
Show context
gejose ◴[] No.45308131[source]
This is one way to look at it, but ignores the fact that most users use third party community plugins.

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".

replies(19): >>45308149 #>>45308208 #>>45308212 #>>45308222 #>>45308224 #>>45308241 #>>45308572 #>>45308600 #>>45308749 #>>45310219 #>>45310642 #>>45310881 #>>45310991 #>>45311185 #>>45311760 #>>45311782 #>>45312975 #>>45313054 #>>45314194 #
1. 0cf8612b2e1e ◴[] No.45308149[source]
Don’t most plugin models work this way? Does VSCode, Vim, Emacs, and friends do anything to segregate content? Gaming is the only area where I expect plugins have limited permissions.
replies(6): >>45308244 #>>45308310 #>>45308373 #>>45308539 #>>45309613 #>>45310771 #
2. jabbany ◴[] No.45308244[source]
Browser extensions also have a relatively robust permissions-based system.

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.

replies(2): >>45308286 #>>45312257 #
3. 0cf8612b2e1e ◴[] No.45308286[source]
I would have thought, but it has been how many years, and as far as I know, there is still no segregation for VSCode extensions. Microsoft has all the money and if they cannot be bothered, not encouraged that smaller applications will be able to iron out the details.
replies(1): >>45308319 #
4. schmichael ◴[] No.45308310[source]
vim and emacs are over 30 years old and therefore living with an architecture created when most code was trusted. Encrypting network protocols was extremely rare, much less disks or secrets. I don't think anything about the security posture of vim and emacs should be emulated by modern software.

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.

replies(3): >>45311209 #>>45312130 #>>45312368 #
5. jabbany ◴[] No.45308319{3}[source]
I think it's just because supply-chain attacks are not common enough / their attack surfaces not large enough to be worth the dev time... yet...

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...

replies(3): >>45309290 #>>45311372 #>>45311771 #
6. erik ◴[] No.45308373[source]
> Gaming is the only area where I expect plugins have limited permissions.

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

replies(1): >>45308573 #
7. gejose ◴[] No.45308539[source]
Perhaps, but I think what you might put onto Obsidian (personal thoughts, journal entries etc) can be more sensitive than code.
8. 0cf8612b2e1e ◴[] No.45308573[source]
I was thinking more Lua/Luaua which make it trivial to restrict permissions. In general, the gaming client has access to a lot more information than it shares, so to prevent cheats from plugins, the developers have to be explicit about security boundaries.
9. connicpu ◴[] No.45309290{4}[source]
The solution at my job is you can only install extensions vetted by IT and updates are significantly delayed. Works well enough but sucks if you want one that isn't available inside the firewall.
10. ◴[] No.45309613[source]
11. raincole ◴[] No.45310771[source]
> Gaming is the only area where I expect plugins have limited permissions.

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.

replies(1): >>45312353 #
12. tlavoie ◴[] No.45311209[source]
I'd love to see software adopt strong capabilities-based models that enforce boundaries even within parts of a program. That is, with the principle of least authority (POLA), code that you call is passed only the capabilities you wish (e.g. opening a file, or a network socket), and not everything that the current process has access to. Thomas Leonard's post (https://roscidus.com/blog/blog/2023/04/26/lambda-capabilitie...) covers this in great detail, and OCaml's newer Eio effect system will has aspects of this too.

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.

replies(1): >>45312303 #
13. anon7000 ◴[] No.45311372{4}[source]
The time has come. The nx supply chain attack a couple weeks ago literally exfiltrated admin tokens from your local dev machine because the VS code extension for nx always downloaded the latest version of nx from npm. And since nx is a monoreop tool, it’s more applicable to larger projects with more valuable tokens to steal.
14. fauigerzigerk ◴[] No.45311771{4}[source]
>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..

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.

15. formerly_proven ◴[] No.45312130[source]
iirc vscode has RCE by design when you use the remote editing feature (i.e. editing files on a server, which is obviously a bad idea anyway, but still a feature) and nobody gives a fuck.
16. sunaookami ◴[] No.45312257[source]
>Browser extensions also have a relatively robust permissions-based system.

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.

17. debugnik ◴[] No.45312303{3}[source]
> OCaml's newer Eio effect system

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.

18. debugnik ◴[] No.45312353[source]
I think they meant games that specifically come with a sandboxed scripting layer. Otherwise, I agree that most mods are indeed just untrusted patches for a native executable or .NET assembly.

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.

19. skydhash ◴[] No.45312368[source]
You have to get out the beaten path to get plugins into Vim/Emacs. It's not difficult, but you don't have access to a marketplace open to the world from the get go. I think Emacs have ELPA, but I would put that at the level of OS repos like Debian/Alpine.