206586 - Allow XBL bindings to dynamically alter their anonymous content structure

Status: RESOLVED WONTFIX

(Core :: XBL, enhancement)

Description

[Benjamin Smedberg]

INTRODUCTION:
I was trying to implement an new version of the <xul:tabbox> element.  Instead
of one long row of tabs that get smaller and smaller, after 10 tabs a new row of
tabs would be born, and so forth.

PROBLEM:
There is no method for an XBL implementation to alter the location of explicit
content in the anonymous content structure. I tried
anonNode.AppendChild(explicitChild) but that changes the explicitChild into an
anonymous element.

SOLUTION:
Implement the ElementXBL interface and add the following methods to operate on
anonymous/explicit content: appendChildXBL, insertBeforeXBL, removeChildXBL,
replaceChildXBL (original spec here:
http://www.mozilla.org/projects/xbl/xbl.html#dom-elementxbl)

MAJOR PROBLEMS:
This opens up all sorts of security questions, which were discussed a bit on
#mozilla. I will attempt to summarize: 

1) There was not agreement about what context XBL scripts themselves ought to 
   operate under. I argue for the context of the URL by which they were loaded.
   Thus chrome://foo.xbl would operate under chrome security privileges, while
   http://123.com/foo.xbl would operate under 123.com security privileges.
   A per-method/per-property flag should be added... whether the property/method
   is private
2) There was disagreement about whether content is/should be allowed to load XBL
   from other domains. Currently, it seems that you can load any XBL you want
   style="-moz-binding: url(&quot;file:///blah-de-blah&quot;) works on Mozilla
   1.3 This is IMO a potentially serious security hole. I'm marking this
   a security bug.
3) Not all scripts should have access to the proposed ElementXBL interface. A
   same-source check against the URL of the XBL document is what I propose; I
   still need to work out what happens in the case of multiple bindings on an
   element. Perhaps ElementXBL would only be exposed on anonymous nodes, not
   any explicit nodes.
4) #3 involves associating each anonymous node with a specific binding, rather
   than just saying "I'm anonymous". I'm still looking at how hard this might
   be.
5) If chrome XBL JS runs under chrome privileges, we either need a security
   audit of all chrome XBL bindings (not pretty), or 

I'm willing to do a lot of the work for this, but will probably need to ask
questions about implementing the DOMCI security stuff. Please let me know if you
think this is totally infeasible. I assume that I will need to file dependent
bugs on some of these issues, so this might become a tracking bug.

Comment 1

[Brendan Eich [:brendan]]

Security-sensitive, bug no security people cc'd?

Wasn't XBL loading restricted during 1.4?

Point (5) trailed off -- what was the "or" clause?

/be

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

2) should be fixed (bug 200691). Could you please test with recent trunk build?

Comment 3

[Benjamin Smedberg]

2) has been fixed, sorry for testing on old builds

5) either needs a security-audit of all our chrome XBL (blech) or some sort of
   flag: <binding id="whatever" runas="(binding|page)"> to determine whether
   scripts in the binding should run in the security context of the page or their
   own URL. This would default to "page" as that is the current effective setting.

checking XBL scripts against the XBL URI (point #1) is not actually necessary
for this bug. It is necessary for things like <input type="file"> implemented as
XBL, and other XBL that might want to use chrome privileges but shouldn't offer
these privileges to the containing page.

Comment 4

[Mitchell Stoltz (not reading bugmail)]

I'm nervous about allowing XUL files in content to load bindings from chrome and
have those bindings run as chrome. That seems dangerous and violates the
philosophy we use just about everywhere - content included by reference gets the
privileges of the including document.

To the other folks CC'd on the bug: Do you think being able to load XBL from a
third-party host is a serious security problem? I don't think so; a page can
load .js files from anywahere, and while this could be used to read certain
files inside a firewall, in practice it would be very difficult to exploit.
Thoughts?

Comment 5

[Benjamin Smedberg]

> I'm nervous about allowing XUL files in content to load bindings from chrome and
> have those bindings run as chrome. That seems dangerous and violates the

I think there is a good case for treating XBL as its own security context. The
prime example is <input type="file"> implemented in XBL, which 1) needs chrome
privileges to run and 2) must not be interfered-with by user-space XBL.

As I said, this is not necessary for this bug. But it does affect how I
implement this, granting scripts access to the ElementXBL interface. So the XBL
module owners need to make a decision, and I will implement it either way.

--BDS

Comment 6

[[e-mail]]

Here's an example of why permissions are so tricky.
Textboxes have a context menu, which performs restricted tasks (clipboard).
Obviously we don't want to grant access to the clipboard from content.
If you grant the binding some sort of permissions, you then have to explain to
Mozilla that your menuitem command handler can access the clipboard while
preventing content from simulating a command event on that menuitem.
I hope that those methods and anonymous nodes will be inaccessible from content.
(The way the bindings have been structured helps in this respect).

Comment 7

[Alex Vincent [:WeirdAl]]

I have an issue or two with the proposed extensions, myself.  :)

firstChildXBL, lastChildXBL, previousSiblingXBL, nextSiblingXBL seem like a
touch of features not needed; ditto for insertBeforeXBL, replaceChildXBL,
removeChildXBL.

IMHO, we should keep XBL-inserted anon content accessible as properties of the
node.xblChildNodes and node.anonymousParent properties.  The seven proposed
extensions are really unnecessary.  Use these properties to transition to the
anonymous content sections, and go from there.

But that's just the purist in me talking.  I can see how they'd be useful.  In
any case, including getters and setters and DOM function calls to do this anyway
would be interesting.

Comment 8

[David Hyatt]

Right now XBL scripts are restricted to match the privileges of the document in
which they are bound, so if content loads a chrome binding, the XBL has only
content privileges.  To do otherwise is to open up a huge can of worms, since an
XBL chrome binding could have an e.g., formatHardDrive() method that could then
be invoked by the Web page.

The security model idea that Stuart Ballard et. al. had proposed at one point
was that the attacher of the binding would determine the security privilege, but
even that has some of the same issues (e.g., the textfield clipboard problem).

Comment 9

[[e-mail]]

Privileged XBL might work if content was denied permission to any privileged 
element (except possibly to dispatch an event).

Comment 10

[Benjamin Smedberg]

Part of XBL2, which will need a consistent plan and implementor at some point.

Comment 11

[Boris Zbarsky [:bzbarsky]]

XBL is now disabled in Firefox (Bug 1583314) and is in the process of being removed from Gecko (Bug 1566221), so closing bugs requesting changes to its implementation as wontfix.