You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Roman Bushmanov <ro...@gmail.com> on 2007/06/26 14:21:49 UTC
[classlib][security] BC provider as default Harmony crypto provider
Hi, all!
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.
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;
};
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.
As a possible solution I can suggest to change the implementation to always
grant the mentioned permission, not depending on the policy file.
Thank you,
Roman
Re: [classlib][security] BC provider as default Harmony crypto provider
Posted by Tim Ellison <t....@gmail.com>.
Mikhail Loenko wrote:
> 2007/6/26, Tim Ellison <t....@gmail.com>:
>> 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
Ah, thanks -- I'd forgotten that.
Tim
Re: [classlib][security] BC provider as default Harmony crypto provider
Posted by Mikhail Loenko <ml...@gmail.com>.
2007/6/26, Tim Ellison <t....@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
>
Re: [classlib][security] BC provider as default Harmony crypto provider
Posted by Tim Ellison <t....@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.
> 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
Re: [classlib][security] BC provider as default Harmony crypto provider
Posted by Roman Bushmanov <ro...@gmail.com>.
Hi, Leo
Actually my custom policy files don't include any SUN-specific policy
grants and the tests pass on RI.
Anyway, I agree to treat the difference as non-bug specifics since you
were able to make RI fail:)
Thank you for your attention to the issue!
Regards,
Roman
On 6/28/07, Leo Li <li...@gmail.com> wrote:
> Hi, Roman:
> I have tried a little and found that SUNJCE also requires a
> java.security.SecurityPermission putProviderProperty.SUN permission while
> BouncyCastle requires a java.security.SecurityPermission
> putProviderProperty.BC permission.
> If we revoke the putProviderProperty.SUN permission in a customized
> security manager, RI also will fail.
> I guess in your policy file, the "putProviderProperty.SUN" permission
> is granted to the SUNJCE class.
> If so, it is just a non-bug difference that RI and harmony just ask for
> different security permissions to let security providers work.
>
> Good luck!
> Leo.
Re: [classlib][security] BC provider as default Harmony crypto provider
Posted by Leo Li <li...@gmail.com>.
Hi, Roman:
I have tried a little and found that SUNJCE also requires a
java.security.SecurityPermission putProviderProperty.SUN permission while
BouncyCastle requires a java.security.SecurityPermission
putProviderProperty.BC permission.
If we revoke the putProviderProperty.SUN permission in a customized
security manager, RI also will fail.
I guess in your policy file, the "putProviderProperty.SUN" permission
is granted to the SUNJCE class.
If so, it is just a non-bug difference that RI and harmony just ask for
different security permissions to let security providers work.
Good luck!
Leo.
On 6/27/07, Roman Bushmanov <ro...@gmail.com> wrote:
>
> Hi, Leo
>
> On 6/26/07, Leo Li <li...@gmail.com> wrote:
> > Hi, Roman:
> > I think it is reasonable to grant permissions to classes in
> extension
> > directory and RI has a similar line in its policy file.
>
> You are right, RI has a statement granting AllPermission to extension
> directory. I've missed that.
>
> However, RI doesn't have the problem with initializing the crypto
> provider then the policy file is redefined complitely. I've seen that
> difference on two tests from functional suite.
>
> Probably they create a provider instance before installing security
> manager, e.g. just before they execute application code. However that
> is not an efficient solution because at vm startup we don't know if we
> need a provider.
>
> > While I must admit that I have tried to delete this line in policy
> file
> > for RI 6.0 and there seems to be no problem to get instance from crypto
> > provider, I think it is due to the RI's security provider(SunJCE) does
> not
> > require some priviledge to work and it is the provider's freedom. (Spec
> does
> > not forbid providers to do this.)
>
> May be I'm missing something but as I understand, each provider
> implementation (a class extending Provider) should set in its
> constructor a variety properties that are required to look up the
> services implemented by this provider. And the only way to do that is
> calling Provider.put() method that performs security access checs. Am
> I right?
>
> > And Roman, is there an application fails due to this issue? If so,
> it
> > deserves us to find a solution.
>
> As I've already noted, I've discovered the issue on two functional
> tests. No other applications.
>
> Thank you,
> Roman
>
--
Leo Li
China Software Development Lab, IBM
Re: [classlib][security] BC provider as default Harmony crypto provider
Posted by Mikhail Loenko <ml...@gmail.com>.
2007/6/27, Roman Bushmanov <ro...@gmail.com>:
> Hi, Leo
>
> On 6/26/07, Leo Li <li...@gmail.com> wrote:
> > Hi, Roman:
> > I think it is reasonable to grant permissions to classes in extension
> > directory and RI has a similar line in its policy file.
>
> You are right, RI has a statement granting AllPermission to extension
> directory. I've missed that.
>
> However, RI doesn't have the problem with initializing the crypto
> provider then the policy file is redefined complitely. I've seen that
> difference on two tests from functional suite.
>
> Probably they create a provider instance before installing security
> manager, e.g. just before they execute application code. However that
> is not an efficient solution because at vm startup we don't know if we
> need a provider.
>
> > While I must admit that I have tried to delete this line in policy file
> > for RI 6.0 and there seems to be no problem to get instance from crypto
> > provider, I think it is due to the RI's security provider(SunJCE) does not
> > require some priviledge to work and it is the provider's freedom. (Spec does
> > not forbid providers to do this.)
>
> May be I'm missing something but as I understand, each provider
> implementation (a class extending Provider) should set in its
> constructor a variety properties that are required to look up the
> services implemented by this provider. And the only way to do that is
> calling Provider.put() method that performs security access checs. Am
> I right?
>
> > And Roman, is there an application fails due to this issue? If so, it
> > deserves us to find a solution.
>
> As I've already noted, I've discovered the issue on two functional
> tests. No other applications.
I suggest to mark this as a non-bug difference from RI
Thanks,
Mikhail
>
> Thank you,
> Roman
>
Re: [classlib][security] BC provider as default Harmony crypto provider
Posted by Roman Bushmanov <ro...@gmail.com>.
Hi, Leo
On 6/26/07, Leo Li <li...@gmail.com> wrote:
> Hi, Roman:
> I think it is reasonable to grant permissions to classes in extension
> directory and RI has a similar line in its policy file.
You are right, RI has a statement granting AllPermission to extension
directory. I've missed that.
However, RI doesn't have the problem with initializing the crypto
provider then the policy file is redefined complitely. I've seen that
difference on two tests from functional suite.
Probably they create a provider instance before installing security
manager, e.g. just before they execute application code. However that
is not an efficient solution because at vm startup we don't know if we
need a provider.
> While I must admit that I have tried to delete this line in policy file
> for RI 6.0 and there seems to be no problem to get instance from crypto
> provider, I think it is due to the RI's security provider(SunJCE) does not
> require some priviledge to work and it is the provider's freedom. (Spec does
> not forbid providers to do this.)
May be I'm missing something but as I understand, each provider
implementation (a class extending Provider) should set in its
constructor a variety properties that are required to look up the
services implemented by this provider. And the only way to do that is
calling Provider.put() method that performs security access checs. Am
I right?
> And Roman, is there an application fails due to this issue? If so, it
> deserves us to find a solution.
As I've already noted, I've discovered the issue on two functional
tests. No other applications.
Thank you,
Roman
Re: [classlib][security] BC provider as default Harmony crypto provider
Posted by Leo Li <li...@gmail.com>.
Hi, Roman:
I think it is reasonable to grant permissions to classes in extension
directory and RI has a similar line in its policy file.
While I must admit that I have tried to delete this line in policy file
for RI 6.0 and there seems to be no problem to get instance from crypto
provider, I think it is due to the RI's security provider(SunJCE) does not
require some priviledge to work and it is the provider's freedom. (Spec does
not forbid providers to do this.)
And Roman, is there an application fails due to this issue? If so, it
deserves us to find a solution.
On 6/26/07, Roman Bushmanov <ro...@gmail.com> wrote:
>
> Hi, all!
>
> 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.
>
> 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;
> };
>
> 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.
>
> As a possible solution I can suggest to change the implementation to
> always
> grant the mentioned permission, not depending on the policy file.
>
> Thank you,
> Roman
>
--
Leo Li
China Software Development Lab, IBM