timeless Assignee
	Description • 17 years ago

a guy wants some in process code to be able to operate on nss without triggering user interaction, this should be possible. it really isn't because psm uses a service for its ui and you can't safely replace such a thing while worrying that a different thread might need the default implementation.

some psm methods include an interfacerequestor to allow for fixing this kind of bug.

the rest I'll fix in a later round (they'll require idl changes...). this should be sufficient for the consumer i'm talking to.

	Kai Engert (:KaiE:)
	Comment 1 • 17 years ago

I'm changing the bug summary from its original

  "Work to enable most nsICertificateDialogs to be overridden using 
   nsIInterfaceRequestor arguments to methods"

to a description that better describes my understanding of the intention:

  "Allow code outside of PSM to simluate affirmative user 
   input to sensitive dialogs."

In more detail, the effect of the patch is that other code
would be able to:

- suppress dialogs like the "bad cert" dialogs,
  effectively overriding trust and allowing connections to any bad sites,
  with the effect of good identity and security indicators shown in chrome.

- suppress dialogs like "do you really want to escrow your private key?"

- silently make PSM assume user confirmation on requests to 
  install and trust CA certs.


The PSM architecture is split into two modules:
- backend code that has all the real logic and decisions
- user interface code that shows information and asks questions

PSM uses mechanisms to allow an embedding application to override the user interface.


So, timeless argues:

  "An extension is able to override our UI to achieve the above,
   extensions should be trusted".


I don't fully understand why not, but timeless claims, he can not use the above mechanism. He is asking for another backdoor that allows the user-interface-context-object passed in to PSM to override the interface as well.


Maybe the above is all ok, because if the user decides to install a new extension, he obviously gives trust to that code which has the same rights as the application.

But I'm still scared about this change, so at least, I don't want to make this decision alone.

	Kai Engert (:KaiE:)
	Comment 2 • 17 years ago

Bob, Dan, Nelson, what do you think?

	Nelson Bolyard (seldom reads bugmail)
	Comment 3 • 17 years ago

I think this is absolutely clearly something we do NOT want to do.
We might as well create a means for a site to cause the whole page to 
appear to be "secure" (lock icon, etc.) when it is not, as to do this 
suggestion.   This suggestion is actually worse, and more dangerous
because it would have longer term effects than for a single page. 

We very expressly do NOT want a web page to EVER be able to change any
user security configuration, or to be able to sign content, without
the user's EXPLICIT ACTIVE permission for EACH and EVERY act.  
That's why crypto.signtext SHOWS the content-to-be-signed to the user
and asks him to approve before each signature.  

Yes, an add-on extension can do this.  A user can install an extension that
completely blows his security entirely, if he chooses, but no mozilla 
product should ever ship with such gaping security holes!

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 4 • 17 years ago

(In reply to comment #3)
> We very expressly do NOT want a web page to EVER be able to change any
> user security configuration

The request is for the ability to do this from privileged (chrome) code.

	Nelson Bolyard (seldom reads bugmail)
	Comment 5 • 17 years ago

Please explain a circumstance in which that would be necessary and desirable.

	timeless Assignee
	Comment 6 • 17 years ago

an extension or application desires to make some use of psm for its own purposes, not in response to a user action - when it does this, the result will not be a web page visible in the browser with a lock icon. as such, the user does not expect a dialog and is likely not around, but certainly doesn't want to be interrupted by a dialog.

standard protocol says that the thing making the request is the thing that answers follow ups. if the user asks to go to a page, you confirm with the user. if some module not acting directly on the user's behalf makes a request, it's your job as a component to confirm with the module - not with a user who doesn't have any interest (and might not exist).

note: this stuff only happens if the object making the request is the object making the request. an extension in general won't be able to use this to influence the requests made by the web browser.

the alternative is that extensions that need to do this hijack the certificate dialogs and randomly (often incorrectly) dismiss dialogs hoping they've dismissed the ones intended for them and not the ones intended for the user. (There are a number of ways to do this, one is to replace the chrome, one is to overlay the chrome, one is to replace the contract that shows the chrome.) please don't make extension authors decrease the security of the system because you don't understand how the component architecture is supposed to be used.

Put another way. Imagine that there are 3 nss users on the system:
web browser
web server
certificate generator

would you force the certificate generator to ask the user whenever it was asked by a shell script to generate a certificate? would you force the user to answer questions relating to the web server whenever it needs to think about a certificate? in our component architecture, all of the above can live in the same process, and the way you distinguish one from another in psm is via the interfacerequestor that represents the actor.

	Nelson Bolyard (seldom reads bugmail)
	Comment 7 • 17 years ago

(In reply to comment #6)
> an extension or application desires to make some use of psm for its own
> purposes, not in response to a user action -

Like, say, signing a document that says "I hereby irrevocably transfer the
deeds to all my real property to Joe Bad Guy", and signs it with the user's
Europe government-issued "qualified Non-Repudiation (NR)cert, without the 
user knowing (of course)?  

> when it does this, the result will
> not be a web page visible in the browser with a lock icon. as such, the user
> does not expect a dialog and is likely not around, but certainly doesn't want
> to be interrupted by a dialog.

The user CERTAINLY does not want anything signed with his NR cert without 
his knowledge.  This is FAR FAR more important than any mere inconvenience
to the extension writer. 

> standard protocol says that the thing making the request is the thing that
> answers follow ups. if the user asks to go to a page, you confirm with the
> user.

Security protocol says: NO ONE but the user himself EVER makes decisions 
about what the user signs, or what certificates he trusts.

> if some module not acting directly on the user's behalf makes a request,
> it's your job as a component to confirm with the module - not with a user who
> doesn't have any interest (and might not exist).

Wrong.  That may be the rule for other UI stuff, but we're talking about
security here.  Ease of UI implementation is secondary.

> the alternative is that extensions that need to do this hijack the certificate
> dialogs and randomly (often incorrectly) dismiss dialogs hoping they've
> dismissed the ones intended for them and not the ones intended for the user.

We should at least attempt to detect extensions tht do this and forcefully 
remove them from AMO.

> (There are a number of ways to do this, one is to replace the chrome, one is 
> to overlay the chrome, one is to replace the contract that shows the chrome.)
> please don't make extension authors decrease the security of the system 
> because you don't understand how the component architecture is supposed to 
> be used.

Extension authors decrease the user's real security by choosing to take 
control away from the user.  That decreases the security of the system.
Don't ever forget that we exist to make things right for the user, not for
the extension writer.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 8 • 17 years ago

(In reply to comment #7)
> (In reply to comment #6)
> > an extension or application desires to make some use of psm for its own
> > purposes, not in response to a user action -
> 
> Like, say, signing a document that says "I hereby irrevocably transfer the
> deeds to all my real property to Joe Bad Guy", and signs it with the user's
> Europe government-issued "qualified Non-Repudiation (NR)cert, without the 
> user knowing (of course)?

I'm not sure why you're assuming that the application is malicious. I don't know exactly why timeless needs this, but I'm pretty sure it isn't because he wants to write a malicious extension!

> The user CERTAINLY does not want anything signed with his NR cert without 
> his knowledge.  This is FAR FAR more important than any mere inconvenience
> to the extension writer.

> Security protocol says: NO ONE but the user himself EVER makes decisions 
> about what the user signs, or what certificates he trusts.

The point is that there isn't a user in timeless' use case. He wants to use NSS/PSM in an automated way, but he can't because the architecture forces dialogs to appear.

> > the alternative is that extensions that need to do this hijack the certificate
> > dialogs and randomly (often incorrectly) dismiss dialogs hoping they've
> > dismissed the ones intended for them and not the ones intended for the user.
> 
> We should at least attempt to detect extensions tht do this and forcefully 
> remove them from AMO.

Sure, malicious extensions and extensions that are doing this in an insecure way should be removed. That doesn't mean there aren't legitimate use cases for this functionality.

Malicious extensions can already bypass dialogs, using the techniques mentioned in timeless' comments. It doesn't make sense to limit and restrict the capabilities of legitimate users of PSM just to make it slightly harder for malicious extension authors.

	Johnathan Nightingale [:johnath]
	Comment 9 • 17 years ago

I don't know about the rest of you, but it's hard for me to reason really effectively about this without knowing more about what the intended use case is supposed to be.  We're forever trading off usability for security or vice versa, and it comes down to how valuable the ease of use gain is, against how egregious the security weakening is.

It feels like building a nice clean API to perform trust operations, potentially legally binding ones, without the user's knowledge, is a non-trivial security weakening, one might even say a large one.  

I sort of resist the argument, too, that they could already do it by hacking the PSM dialogs in an extension.  While this statement is true, it's also nearly tautological.  Of course they can do arbitrary things if they overlay and deliberately mess with security infrastructure -- if that's a good reason to make this change, it's a good reason to make any change.  

I don't actually think that timeless wants that to be his primary point anyhow.  I don't want to speak for him, but I think he wants to argue this on its merits - that this is functionality that PSM should include because it's a good idea, not because there is already a hacky workaround.  It's not my call to make, but right now my trouble is seeing what those merits are, because I'm having difficulty understanding how prevalent this use case is, and what innovation we are potentially stifling in the name of security.  

Creating the API has a permissive effect on programmers - it suggests that this has been considered within the context of overall security integrity and implemented in a way that is consistent with that.  If programmers see that their only way around it is to do evil things with dialog overlays and simulated clicks, it might give them sufficient pause to realise they're doing a scary thing.  I know you already know all this, but my point is that this seems to be a thing which is pretty scary to people who think about security a lot, so it would help to know how big the win is expected to be. 

	timeless Assignee
	Comment 10 • 17 years ago

For reference, in case my original comment 0 wasn't clear enough, this bug was not something I filed for myself or my employer. For MicroB, we indeed did control the authentication prompts and therefore would never have a need to do things as described here.

Here's an alternate version of the equation, suppose we had a way for PSM/NSS to maintain two independent sets of databases, one for user sponsored interactions and one for non user sponsored interactions. If we could properly isolate these databases and allow an automated server (XPCOM driven) to operate on the non user database, would that make people happier?

The use case is something like this:
I want to write an XPCOM based web server. The web server wants to expose a way for the admin of the web server to upload a new certificate chain, including a new root certificate. It uses PKI/etc. in order to authenticate the administrative user. This all runs inside a gecko process (gecko is the web server, there's no Apache/IIS/NES/...). A web interface <input type=file> is used to enable the administrator to send the new certificates to the web server. The web server runs physically headless, the only "UI" it has is via HTTP. Now, there are two possibilities:
A. the developer writes their own authentication dialog implementation which replaces the standard one (the perils of this are now documented in bug 406724).
B. the developer writes code that uses an API more like this one, but possibly with a restriction that it be applied to an alternate certificate store (i certainly wouldn't mind this).

Here's the catch:
Normal operation of this web server is most certainly headless. Imagine that someone wants to "debug" the web server. The logical way to do it is to run it in process of a normal gecko (Firefox/SeaMonkey) with Venkman (assume that Venkman's threading problems are fixed, I have patches from 2 years ago that mostly address this). Now in this scenario, there are two operations:
1. a user who might need to be able to use the web browser to make requests
2. an XPCOM server process (in process because jsd_xpc can't do out of process debugging, unlike its older Corba based long lost sibling)

If the developer uses process A for 2, then the user in 1 suffers (see secret bug). If the developer uses process B for 2, then the user in 1 gets the standard unhacked dialog and untainted databases, and hopefully people are much less unhappy.

Note to Kaie: my summary was what I wanted, your summary describes path A, which is very clearly obviously possible (as i described in comments to him which he summarized in comment 1, and which is again clearly possible and obviously not ideal as seen in bug 406724).

	Nelson Bolyard (seldom reads bugmail)
	Comment 11 • 17 years ago

Sounds like an extension to me.

	Kai Engert (:KaiE:)
	Comment 12 • 16 years ago

Comment on attachment 272745 [details] [diff] [review]
check interfacerequestor for nsICertificateDialogs and friends

r- because of the earlier comments, and because I currently don't know whether this patch is still valid.

Looking at the patch, I find that 99% of the patch seem to be cleanup noise.

I find such patches very hard to deal with. 99% noise and somewhere (where?) a small change for the actual desired behavior change.

I'm unable to find your behavior change.