Worm Prevention (Security Discussion)

Each option will be given a label for discussion.

• Using X-Content-Type-Options: nosniff, we can enforce that only javascript MIMEs are executed by <script> and only CSS MIMEs are executed by <style>.
• Using Content-Security-Policy can be used to disable all execution/embeds on a page, limit the types of content that may be embedded, and limit the sources of content.

Problem Definition

Beaker gives apps served over dat:// access to the Dat Web API. This means it's possible to write files to other sites or apps. That opens the possibility of worm infections. (Imagine a snippet which simply appends itself to the index.js of every writable app on the device.)

The simplest solution is simply to disable writes entirely -- but that would destroy the point of Beaker. We want to let users write custom software, share that software freely, and have that software interact.

Solutions fall into two categories: trust-management, and capability-reduction.

• Trust-management asks, "Is it safe to give capabilities to this code?"
• Capability-reduction asks, "Can we reduce the trust invested in this code?"

To manage trust, we need a mature network of identities, reputations, and software audits which does not yet exist, and therefore must be a future goal.

To reduce capabilities, we use sandboxing and permission rules to make worms more difficult to author. The question is, can we avoid making valid software hard to author as well?

Capability-reduction is available now and will be the topic of this wiki.

Options

Fighting injections into non-executable files

read-sanitation Build sanitation into read functions

Whenever readFile is called with 'utf-8' encoding, automatically convert '<' to < and '>' into >. This could be disabled with the option {sanitize: false}.

Premise: This would reduce the likelihood of successful injections by handling sanitation for applications.

Cons:

• Slower reads.
• May corrupt data.

Fighting injections into executable files

no-exec-write Dont allow sites to write executable code

No site is allowed to write .html, .js, or .css.

Premise: Noboby is allowed to write code, so worms shouldn't be able to spread.

Cons:

• Can't make editor applications.
• I thought this was America! (Very freedom-hating.)
• Injections would still be writable in "non executable" code such as a .json. Apps that forget to sanitize input would be vulnerable to this.

exec-write-perm Make 'write executable code' a special permission

Sites must request special permission to write .html, .js, or .css.

Premise: a variation of no-exec-write which does allow executable-code writes, but only behind a permission prompt.

Pros:

• Editor-apps can be made.

Cons:

• Editor-apps can't modify editor-apps.
• Injections would still be writable in "non executable" code such as a .json. Apps that forget to sanitize input would be vulnerable to this.
• It's unclear whether adding Yet Another Permission Prompt would make a difference. Aren't users going to just click Yes?

protected-flag Allow sites to be marked unwritable

Site authors could set a protected flag in the dat.json which disables writes from other sites.

Premise: A security-sensitive application would be protected, enabling only changes from Beaker itself (via bkr).

Cons:

• Somewhat of an advanced feature.