You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2006/11/24 10:13:17 UTC
[classlib][security] Changing system property java.home may cause
incorrect initialization of java.security.Security class
Alexey Varlamov (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/HARMONY-2163?page=comments#action_12452378 ]
>
> The only consistent way to fix this (as I see) is to preload and init Security class early, somewhere during bootstrap. OTOH this may increase bootstrap time a bit...
> What do you think?
The problem appears to be that we don't set defaults if we cannot find
the properties file(s).
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
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib] Launcher fails to find properties location when bad -Djava.home is specified on the command line
Posted by Alexey Varlamov <al...@gmail.com>.
Just to be accurate, this not the launcher who uses "java.home",
rather luni natives invoke readClassPathFromPropertiesFile regardless
of the way VM is created and which launcher is used, if any.
I do not think this system is wrong *by design*. Reasonable thing to
do is to introduce more specialized property like "o.a.h.vm.home"
instead of using conventional "java.home", to reduce probability of
collision with user application specific utilization of properties.
Frankly speaking, I hardly imagine conscious application which needs
modification of "java.home". Accordingly to specification, "java.home"
defines Java installation directory, so changing it is at least weird.
--
Regards,
Alexey
2006/11/25, Gregory Shimansky <gs...@gmail.com>:
> Gregory Shimansky wrote:
> > Probably Geir meant internal native VM value for java.home property. Java
> > program cannot change that. Even setting this property with -D command line
> > switch won't give any effect on drlvm because it will be overridden on the
> > initialization... and now that I've written it and tried to override
> > java.home on command line, drlvm crashed :(
> >
> > The bug however seems to be in the launcher because it didn't set
> > org.apache.harmony.boot.class.path to any value, so the property is NULL. I'm
> > going to take a look (recompiling classlib with debug since it has no symbols
> > by default).
>
> A short investigation shows that launcher parses -Djava.home passed on
> the command line. Later on while classlib is initialized the function
> readClassPathFromPropertiesFile calls properties_load with file name
> formed as ${java.home}/lib/boot/bootclasspath.properties. If this file
> is not found and properties_load, then no value is assigned to
> org.apache.harmony.boot.class.path.
>
> I think this system is wrong. The launcher should not pay attention to
> java.home passed on the command line. The location should be found from
> the executable path probably. RI doesn't crash or fail its boot classes
> when I specify bad -Djava.home on the command line.
>
> --
> Gregory
>
>
[classlib] Launcher fails to find properties location when bad -Djava.home
is specified on the command line
Posted by Gregory Shimansky <gs...@gmail.com>.
Gregory Shimansky wrote:
> Probably Geir meant internal native VM value for java.home property. Java
> program cannot change that. Even setting this property with -D command line
> switch won't give any effect on drlvm because it will be overridden on the
> initialization... and now that I've written it and tried to override
> java.home on command line, drlvm crashed :(
>
> The bug however seems to be in the launcher because it didn't set
> org.apache.harmony.boot.class.path to any value, so the property is NULL. I'm
> going to take a look (recompiling classlib with debug since it has no symbols
> by default).
A short investigation shows that launcher parses -Djava.home passed on
the command line. Later on while classlib is initialized the function
readClassPathFromPropertiesFile calls properties_load with file name
formed as ${java.home}/lib/boot/bootclasspath.properties. If this file
is not found and properties_load, then no value is assigned to
org.apache.harmony.boot.class.path.
I think this system is wrong. The launcher should not pay attention to
java.home passed on the command line. The location should be found from
the executable path probably. RI doesn't crash or fail its boot classes
when I specify bad -Djava.home on the command line.
--
Gregory
Re: [classlib][security] Changing system property java.home may cause incorrect initialization of java.security.Security class
Posted by Gregory Shimansky <gs...@gmail.com>.
On Friday 24 November 2006 23:17 Tim Ellison wrote:
> Geir Magnusson Jr. wrote:
> > Tim Ellison wrote:
> >> Geir Magnusson Jr. wrote:
> >>> Isn't java.home set on vm start and immutable?
> >>
> >> No.
> >
> > "No" what?
>
> ?? It is untrue that java.home is set on vm start and immutable.
Probably Geir meant internal native VM value for java.home property. Java
program cannot change that. Even setting this property with -D command line
switch won't give any effect on drlvm because it will be overridden on the
initialization... and now that I've written it and tried to override
java.home on command line, drlvm crashed :(
The bug however seems to be in the launcher because it didn't set
org.apache.harmony.boot.class.path to any value, so the property is NULL. I'm
going to take a look (recompiling classlib with debug since it has no symbols
by default).
> e.g.
>
> public static void main(String[] args) {
> System.out.println(System.getProperty("java.home"));
> System.setProperty("java.home", "anything I want it to be");
> System.out.println(System.getProperty("java.home"));
> }
>
> produces:
>
> C:\java\IBM JDK 5.0\SR3\jre
> anything I want it to be
Yes this changes the property on java level, but VM ignores the change or it
should better do it. So on the native level the property is immutable and set
on VM startup.
--
Gregory
Re: [classlib][security] Changing system property java.home may cause
incorrect initialization of java.security.Security class
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison wrote:
> Geir Magnusson Jr. wrote:
>> Tim Ellison wrote:
>>> Geir Magnusson Jr. wrote:
>>>> Isn't java.home set on vm start and immutable?
>>> No.
>> "No" what?
>
> ?? It is untrue that java.home is set on vm start and immutable.
>
> e.g.
>
> public static void main(String[] args) {
> System.out.println(System.getProperty("java.home"));
> System.setProperty("java.home", "anything I want it to be");
> System.out.println(System.getProperty("java.home"));
> }
>
> produces:
>
> C:\java\IBM JDK 5.0\SR3\jre
> anything I want it to be
>
>
Thanks - why would anyone want this to be mutable?
geir
Re: [classlib][security] Changing system property java.home may cause
incorrect initialization of java.security.Security class
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> Tim Ellison wrote:
>> Geir Magnusson Jr. wrote:
>>> Isn't java.home set on vm start and immutable?
>>
>> No.
>
> "No" what?
?? It is untrue that java.home is set on vm start and immutable.
e.g.
public static void main(String[] args) {
System.out.println(System.getProperty("java.home"));
System.setProperty("java.home", "anything I want it to be");
System.out.println(System.getProperty("java.home"));
}
produces:
C:\java\IBM JDK 5.0\SR3\jre
anything I want it to be
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib][security] Changing system property java.home may cause
incorrect initialization of java.security.Security class
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison wrote:
> Geir Magnusson Jr. wrote:
>> I don't understand. If I can modify java.home, it means I can control
>> any properties the VM comes up with, right?
>
> Yes, for some definition of 'any'.
>
>> Isn't java.home set on vm start and immutable?
>
> No.
"No" what?
geir
Re: [classlib][security] Changing system property java.home may cause
incorrect initialization of java.security.Security class
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> I don't understand. If I can modify java.home, it means I can control
> any properties the VM comes up with, right?
Yes, for some definition of 'any'.
> Isn't java.home set on vm start and immutable?
No.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib][security] Changing system property java.home may cause
incorrect initialization of java.security.Security class
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
I don't understand. If I can modify java.home, it means I can control
any properties the VM comes up with, right? Isn't java.home set on vm
start and immutable?
geir
Tim Ellison wrote:
> Alexey Varlamov 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...
>
> I agree.
>
> Regards,
> Tim
>
Re: [classlib][security] Changing system property java.home may cause
incorrect initialization of java.security.Security class
Posted by Tim Ellison <t....@gmail.com>.
Alexey Varlamov 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...
I agree.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib][security] Changing system property java.home may cause incorrect initialization of java.security.Security class
Posted by Boris Kuznetsov <bo...@gmail.com>.
Agree
On 11/24/06, Alexey Varlamov <al...@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 <bo...@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 <al...@gmail.com> wrote:
> > > +1
> > >
> > > 2006/11/24, Tim Ellison <t....@gmail.com>:
> > > > Alexey Varlamov wrote:
> > > > > 2006/11/24, Tim Ellison <t....@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
Re: [classlib][security] Changing system property java.home may cause incorrect initialization of java.security.Security class
Posted by Alexey Varlamov <al...@gmail.com>.
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 <bo...@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 <al...@gmail.com> wrote:
> > +1
> >
> > 2006/11/24, Tim Ellison <t....@gmail.com>:
> > > Alexey Varlamov wrote:
> > > > 2006/11/24, Tim Ellison <t....@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
>
Re: [classlib][security] Changing system property java.home may cause incorrect initialization of java.security.Security class
Posted by Boris Kuznetsov <bo...@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 <al...@gmail.com> wrote:
> +1
>
> 2006/11/24, Tim Ellison <t....@gmail.com>:
> > Alexey Varlamov wrote:
> > > 2006/11/24, Tim Ellison <t....@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
Re: [classlib][security] Changing system property java.home may cause incorrect initialization of java.security.Security class
Posted by Alexey Varlamov <al...@gmail.com>.
+1
2006/11/24, Tim Ellison <t....@gmail.com>:
> Alexey Varlamov wrote:
> > 2006/11/24, Tim Ellison <t....@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.
>
Re: [classlib][security] Changing system property java.home may cause
incorrect initialization of java.security.Security class
Posted by Tim Ellison <t....@gmail.com>.
Alexey Varlamov wrote:
> 2006/11/24, Tim Ellison <t....@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.
Re: [classlib][security] Changing system property java.home may cause incorrect initialization of java.security.Security class
Posted by Alexey Varlamov <al...@gmail.com>.
2006/11/24, Tim Ellison <t....@gmail.com>:
> Alexey Varlamov (JIRA) wrote:
> > [ http://issues.apache.org/jira/browse/HARMONY-2163?page=comments#action_12452378 ]
> >
> > The only consistent way to fix this (as I see) is to preload and init Security class early, somewhere during bootstrap. OTOH this may increase bootstrap time a bit...
> > What do you think?
>
> The problem appears to be that we don't set defaults if we cannot find
> the properties file(s).
Oh, I just overlooked the practical root cause. Nice catch!
>
> 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.
--
Alexey
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>