harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Boris Kuznetsov" <boris.v.kuznet...@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:26:23 GMT
Agree

On 11/24/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> 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
> >
>


-- 
Best regards,
Boris Kuznetsov
Intel Middleware Products Division

Mime
View raw message