harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [classlib][security] Changing system property java.home may cause incorrect initialization of java.security.Security class
Date Fri, 24 Nov 2006 11:09:58 GMT
Boris, for the security-sensitive applications, there is appropriate
guard in place:

public SecurityManager() {
	SecurityManager security = System.getSecurityManager();
	if (security != null) {
            security.checkPermission(RuntimePermission.permissionToCreateSecurityManager);
        }
        Class<?> type = Security.class; // initialize Security properties
        if (type == null) {
            throw new AssertionError();
        }
}

I believe this is enough. In fact if the code has enough privileges to
modify such principal system properties, there might be even more
severe problems...

2006/11/24, Boris Kuznetsov <boris.v.kuznetsov@gmail.com>:
> Proposed update will resolve the providers issue in the concrete case.
> But it is not resolve the problem completely.
>
> The posibility to load malicious 'java.security' file still exist
> (after changing java.home system property before Security class
> initilaization). So, the application may replace any security property
> and policy file.
>
> On 11/24/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> > +1
> >
> > 2006/11/24, Tim Ellison <t.p.ellison@gmail.com>:
> > > Alexey Varlamov wrote:
> > > > 2006/11/24, Tim Ellison <t.p.ellison@gmail.com>:
> > > >> So how about we implement Security#registerDRLProviders() (maybe with
a
> > > >> method name change) to register:
> > > >>
> > > >> security.provider.1=org.apache.harmony.security.provider.cert.DRLCertFactory
> > > >>
> > > >> security.provider.2=org.apache.harmony.security.provider.crypto.CryptoProvider
> > > >>
> > > >> security.provider.3=org.apache.harmony.xnet.provider.jsse.JSSEProvider
> > > >> security.provider.4=org.bouncycastle.jce.provider.BouncyCastleProvider
> > > >>
> > > >> Thoughts?
> > > >> Tim
> > > >
> > > > Well, there is a number of other sensitive keys without hardcoded
> > > > defaults, e.g. package.access, probably bunch of ssl.* keys. Therefore
> > > > I presume it should be Security#defaultConfig() then.
> > >
> > > Sorry, I wasn't clear.  There is already a method called
> > > Security#registerDRLProviders() that does nothing.  I suggest that we
> > > implement it as I described above.
> > >
> > > There may well be other properties that need a default value, but they
> > > would be fixed elsewhere -- presumably where they are used, in case the
> > > file exists but does not define those properties any more.
> > >
> > > If you agree with the default providers I can make that change.
> > >
> > > Regards,
> > > Tim
> > >
> > > --
> > >
> > > Tim Ellison (t.p.ellison@gmail.com)
> > > IBM Java technology centre, UK.
> > >
> >
>
>
> --
> Best regards,
> Boris Kuznetsov
> Intel Middleware Products Division
>

Mime
View raw message