Closed Bug 53493 Opened 24 years ago Closed 24 years ago

chrome html should get system principal

Categories

(Core :: Security, defect, P1)

Product:
Core
Component:
Security
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: security-bugs, Assigned: security-bugs)

References

Details

(Whiteboard: [nsbeta3-])

Attachments

(1 file)

Fix - Hyatt, can you review?
841 bytes, patch
Details | Diff | Splinter Review 
In an attempt to calm security fears, I restricted use of the system principal
in chrome to .xul files only. This has caused problems for folks who put html
files in chrome; I didn't realize the need here. Apparently the about:plugins
code is broken because of this. I'm willing to give the system principal to html
files, pending a chrome security review which I'll hold soon.
P1, because some features are broken.
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: --- → M19
nominated for nsbeta3+ to get about:plugins in for PR3/RTM. Note that if this
got minus-ed, we should convert plugins.html to xul.

Also, add dependency for
Blocks: 36908
Keywords: nsbeta3
*** Bug 54237 has been marked as a duplicate of this bug. ***
Mitch, what is broken from the user perspective? I still see the plugins listed
when using Mozilla bits, is this commercial only? Why would this need to go into
the beta rather than just rtm?  What is the risk?

go back and read my comment in 36908. I wound up giving up on localizing
about:plugins and just checked in the old version from classic (presumably
the one used for ages in 4.x). This bug would be necessary if we wanted to 
keep about:plugins as an html file and had to use string bundles from it.

The about:plugins that is currently checked in works, but doesn't follow
the localizability guidelines. The way to fix this is to either fix this
bug and allow the use of string bundles in html files or to re-write 
about:plugins with xul. (right?). In the long term, maybe the latter is
the best option. Didn't rginda have a component viewer working before?
Is it a good idea to list plugins and components together? Sorry for the
delayed reaction on this. i'm out this week.
I don't think this is critical enough to get into the branch for beta3 at this
point. The plugin info comes up in a web page, and the English can be run
through an online translator in a pinch. nsbeta3-, nominating for rtm.
Keywords: rtm
Whiteboard: [nsbeta3-]
Hyatt needs to bless this.  Do we have any .html files in chrome that try to use 
XPConnect, etc.?  This suddenly seems low priority, given the English-only HTML 
file that was checked in.  If the right fix is to create about-plugins.xul, then 
we should not commit the patch in this bug, and encourage "chrome HTML".

/be
I wrote:
> we should not commit the patch in this bug, and encourage "chrome HTML".

which should have read "not commit [...], thereby encouraging ...".  IOW, if we 
can wait to do about-plugins.xul later, and we don't need system privileges for 
about-plugins.html now, then let's push off this bug, or close it WONTFIX.

Hyatt, should we support privileged HTML in chrome?

/be
html files in chrome have no system principal (XPConnect) access right now. 
Perhaps more damaging, html files in chrome have no access to the contents of 
chrome XUL documents. Apparently this is breaking the Transformiix/XSLT processor 
(bug 54237). Is this a priority? Are there any other html files in chrome which 
need XPConnect or DOM access to XUL documents? We might be breaking other chrome 
html that I don't know about. Checking in this fix doesn't change our security 
story significantly if at all, and it would solve some problems.
Blocks: 54237
Wow, I didn't know XSL/T used HTML in chrome.  LXR pointer?

Someone please cough up a survey of chrome:....html files.

/be
The current question is whether nsbeta3 can go out without this fix.

Well, is Transformiix truly busted without this fix?  Does Netscape care about 
Transformiix working on PR3?  Cc'ing nisheeth.

/be
It would seem to be correct to allow any chrome documents (regardless of type) 
to have a system principal.  However, I am curious why someone is using chrome 
HTML.

Of course they could be using chrome HTML in a content area, which would be 
reasonable.  This is similar to what we do with FTP/file directory listings.  
They load in the content area but are still chrome URLs.

If all chrome file types should get the system principal, why are we bothering 
with the extension check for .xul or .xul and .html?  Is it on account of .js 
files?  Hrm.

/be
Checking the file extension is not to fix any specific exploit, just an extra 
measure of security. Hyatt assured me that any files (.js files in particular) 
included in a xul or html page get the principal of the document. Just in case 
that isn't always the case, we assign system principals only to the document (xul 
or html) itself. 

replacing blocks bug 36908 (implement about:plugins with
bug 56863 (make about:plugins localizable).
Blocks: 56863
No longer blocks: 36908
Fix checked in, trunk and branch. .xul, .html, and .xml extensions all get the
system principal now.

Marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Verified per mstoltz's comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.