harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][security] BC provider as default Harmony crypto provider
Date Tue, 26 Jun 2007 13:33:34 GMT
Roman Bushmanov wrote:
> I would like to raise a question concerning our specifics in using
> Bouncy Castle as default crypto provider. I can't say definitely that
> we have a bug here but it would be great to hear from our security
> gurus on this subject.
> 
> The point is that a security provider can be initialized correctly only by
> trusted code i.e. application working w/out security manager or application
> with certain security permission granted. For example,
> java.security.SecurityPermission putProviderProperty.BC permission is
> required by BC provider to be granted to initialize properly.

Yes, I seem to recall this discussion from a long time ago when we were
trying to get BouncyCastle to work with Harmony code.  Ideally we would
'own' some trusted algorithms in the bootclasspath that allow us to open
and check signed JARs.

> The problems appear because of dynamic initialization of security providers
> in Harmony. In other words a provider is being initialized at the first
> request by the application code which is not considered as trusted. To
> address this issue, our implementation has the following statement in the
> default policy file
> 
> grant codeBase "file:${java.home}/lib/ext/*" {
>    permission java.security.AllPermission;
> };

There is a line for granting all permissions to extensions in the RI
too.  So that is not the problem per se.

> In my opinion, this is not an ideal solution to the problem. If
> someone redefines the default policy file at runtime with - 
> Djava.security.policy==my.policy and does not include in my.policy
> the above statement, the crypto provider will not work. That means
> the user should know the specifics of our implementation and should
> tune his or her policy files to work on our java. At the same time,
> RI doesn't have such limitation.

or if they change the extensions directory and point it somewhere where
there are no algorithms for us to find...

> As a possible solution I can suggest to change the implementation to always
> grant the mentioned permission, not depending on the policy file.

Is that the right solution?  Shouldn't we be looking for algorithms that
are inherently trusted on the bootclasspath?

Regards,
Tim

Mime
View raw message