You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/README.md
+70-1Lines changed: 70 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -37,7 +37,76 @@ Isolation was done using the [Secure ECMAScript](https://github.com/endojs/endo)
37
37
38
38
Interactive Live2Ds were taken from [Z_DK's Steam Workshop](https://steamcommunity.com/id/xingsuileixi/myworkshopfiles/?appid=431960)
39
39
40
-
One more thing: we need to take care of DOM script tags that plugins can add when have the DOM access. Otherwise, this sandbox can be escaped. Maybe we can overwrite the `document.createElement` before freezing it? And just to be sure, listen for `head` element changes for possible script tag additions?
40
+
<details>
41
+
We need to take care of DOM script tags that plugins can add when have the DOM access. Otherwise, this sandbox can be escaped. Maybe we can overwrite the `document.createElement` before freezing it? And just to be sure, listen for `head` element changes for possible script tag additions?
42
+
43
+
Update: Seems like giving DOM access to the compartment basically ruins the whole purpose of plugin isolation, since one can add a JS code to any DOM element that will be executed in the global scope.
44
+
45
+
Well, let's make these permissions then?
46
+
47
+
- Full DOM access
48
+
- File System access (window.__TAURI__.fs)
49
+
- System shell access (window.__TAURI__.shell)
50
+
- ...other Tauri-specific plugins access
51
+
52
+
How to adapt to these rules? Do I really need compartments here? Isn't it better to just use `new Function` at this point? What to do about script tags and the above DOM element JS executions? Should I expose Tauri API through `window` object? How to import and share Tauri API then?
53
+
54
+
---
55
+
56
+
After some thoughts, I decided to go with this approach:
57
+
58
+
Tauri API **will not** be exposed through `window`
59
+
60
+
Account sign in is made through another webview window with no plugin access to prevent any possible security vulnerabilities.
61
+
62
+
- Kaede User Repository (KUR) - plugins that are free to publish for anyone. Will use Secure ECMAScript Compartments for not full DOM access, otherwise they are executed with `new Function`
63
+
- Moderated plugins - every plugin publish/update goes through my checks. I only need plugin's source code and build manual. Executed with `new Function` or `Module Federation Runtime API`, have full DOM access by default, only require Tauri API scope permissions (fs, shell, global shortcuts, network, os info, etc.) from user
64
+
65
+
Permissions:
66
+
67
+
Runs in compartment:
68
+
69
+
- CSS: Apply CSS stylesheet - Custom
70
+
- | Edit/replace element class list (by id)
71
+
- | Edit element styles (by id)
72
+
73
+
Runs in `new Function` or Module Federation Runtime API (`eval`):
74
+
75
+
Note: I need to generalize these, because seeing 30 permissions that vary from doing 1 simple ass thing (tauri-core-app) to doing 50+ dangerous things (tauri-plugin-fs/tauri-plugin-shell) is not ok
76
+
77
+
- Website capabilities: everything that HTML & JS & CSS offers (no access to Tauri API)
78
+
- Tauri Core: Allow to change application theme (not the UI) - App
79
+
- | Emit/listen events to/from the backend - Event
0 commit comments