harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: [classlib][security] BC provider as default Harmony crypto provider
Date Tue, 26 Jun 2007 13:37:01 GMT
2007/6/26, Tim Ellison <t.p.ellison@gmail.com>:
> 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.

We have this already. Our small
org.apache.harmony.security.provider.crypto.CryptoProvider
verifies signature of JARs

Thanks,
Mikhail


>
> > 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