I've been thinking about the interaction of security and necko recently, and I
would like to propose two new APIs for necko as follows (details are modifiable;
I'll explain what I'm trying to achieve below):
interface nsISecureIOService : nsIIOService {
nsIChannel secureNewChannelFromURI(in nsIURI aURI, in nsISupports aContext);
nsIChannel secureNewChannel(in AUTF8String aSpec,
in string aOriginCharset,
in nsIURI aBaseURI,
in nsISupports aContext);
};
interface nsISecureProtocolHandler : nsIProtocolHandler {
// Not sure what the best api is here
};
The first api will solve the problem of callers forgetting to call CheckLoadURI.
The idea is that the IOService will get some other service by contract (like
it does for channel redirects), or even have some category of services that are
interested, and notify them all that a new channel is being created for some URI
with some context. The security manager can then QI the context to nsIPrincipal
and do a CheckLoadURI check. This way all callers of secureNewChannelFromURI
are automatically safe as far as CheckLoadURI goes. Note that this does require
that callers have the principal involved, which means that we may need api
additions to things like nsIWebNavigation too. Or we could keep it as-is and
require nsIWebNav callers to do their own CheckLoadURI checks, I suppose... But
I'd rather not do that.
I've been toying with having this method also call content policy, since there
is at least one content policy we have that's actually a security check. That
would require passing a lot more data to necko, though, so I'm not sure how well
that would work....
The second API is intended to solve the problem of us hardcoding a list of
schemes in security manager, with all other schemes being allAccess for
CheckLoadURI purposes. It would be better if we could interrogate the protocol
handlers themselves for what they think about who should be able to load them.
Most simply, this can be a single function that returns what capability is
needed to access the protocol (eg UniversalXPConnect, etc). But maybe there's a
better api here?
Thoughts? I'd really rather like to do this for 1.9 if we can...
-Boris
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
