Protecting system properties (was: Re: [jira] Commented: (DERBY-1387) Add JMX extensions to Derby)

[John Embretsen <Jo...@Sun.COM>]

Daniel John Debrunner wrote:
> Rick Hillegas wrote:
> 
>> Thanks for those experiments, John. When I boot the network server, it 
>> installs the default Derby server policy. Even then I can still click 
>> through the system properties via the Runtime MBean. This surprises me 
>> because the default policy only grants permissions to the Derby jars.
> 
> I would guess the system jmx beans are jre system code and thus granted 
> all permissions.

Right. And fiddling with the system's default security policy for libraries from
the Java platform (java.*, javax.*) is not something I recommend. I am guessing
here, but I have a feeling that at least 99.9% of our users will accept this
risk instead of going that route.

There are most likely other ways to deal with this particular source of
exposure, by jumping through a number of hoops here and there (e.g. by disabling
or somehow modifying the RuntimeMXBean whenever Derby boots), but do we really
want to go that way?

There may be a "gazillion" other ways to view system properties of a given JVM
today or in the future - and we would need to keep up with that...

In my opinion, once you choose to expose your application to other, potentially
harmful, users through JMX or other means, you necessarily need to deal with a
potentially higher risk level.

We, as Derby developers, should strive to keep the sensitivity of the
information stored as (derby) system properties to a minimum. For example, we
should recommend against defining usernames and passwords in cleartext as system
properties (especially in scenarios where remote JMX is enabled), and should
provide better alternatives to the users.

It is, as Rick mentioned, hard to determine the value of a given property in the
hands of an malevolent user, but I am inclined to think this is something we
could live with. We cannot protect against everything.
Does anyone know how other comparable systems handle this issue?

Anyway, just my 2 cents...


-- 
John

Re: Protecting system properties

["John H. Embretsen" <Jo...@Sun.COM>]

Daniel John Debrunner wrote:
> John Embretsen wrote:
>
> [lots of good comments snipped]
>
>> We, as Derby developers, should strive to keep the sensitivity of the
>> information stored as (derby) system properties to a minimum. For 
>> example, we
>> should recommend against defining usernames and passwords in 
>> cleartext as system
>> properties (especially in scenarios where remote JMX is enabled), and 
>> should
>> provide better alternatives to the users.
>
> A better alternative already exists today. Derby system level 
> properties can be specified in derby.properties, none of these values 
> are then set as JVM system properties, and thus they will not appear 
> to any standard jmx bean.

Yes, this is a good thing. Still not optimal, but it certainly helps. We 
could probably be more explicit about the differences in the manuals.

> Exposing these (or a security conscious subset of them) through 
> Derby's SystemMBean is fine, though I'm not sure that's what is being 
> proposed by the jmx changes. I.e. does SystemMbean just display the 
> value of the jvm system property or the value that derby is using (set 
> as a jvm system property or in derby.properties)?

I think the latter (the value derby is using). I think this is best,
from a usability perspective. (In the SystemMBean, most properties are
fetched using the getSystemProperty(...) method of
org.apache.derby.iapi.services.property.PropertyUtil). What to expose
through our own JMX beans is luckily easier to control than what is
available via platform features.

-- 
John

Re: Protecting system properties

[Rick Hillegas <Ri...@Sun.COM>]

Daniel John Debrunner wrote:
> John Embretsen wrote:
>
> [lots of good comments snipped]
>
>> We, as Derby developers, should strive to keep the sensitivity of the
>> information stored as (derby) system properties to a minimum. For 
>> example, we
>> should recommend against defining usernames and passwords in 
>> cleartext as system
>> properties (especially in scenarios where remote JMX is enabled), and 
>> should
>> provide better alternatives to the users.
>
> A better alternative already exists today. Derby system level 
> properties can be specified in derby.properties, none of these values 
> are then set as JVM system properties, and thus they will not appear 
> to any standard jmx bean.
I think this will be a sensible recommendation to make when we roll out 
JMX-based tools for Derby. Potentially "derby.system.home" will still be 
visible as a system property.
>
> Exposing these (or a security conscious subset of them) through 
> Derby's SystemMBean is fine, though I'm not sure that's what is being 
> proposed by the jmx changes. I.e. does SystemMbean just display the 
> value of the jvm system property or the value that derby is using (set 
> as a jvm system property or in derby.properties)?
>
> Dan.
>
>

Re: Protecting system properties

[Daniel John Debrunner <dj...@apache.org>]

John Embretsen wrote:

[lots of good comments snipped]

> We, as Derby developers, should strive to keep the sensitivity of the
> information stored as (derby) system properties to a minimum. For 
> example, we
> should recommend against defining usernames and passwords in cleartext 
> as system
> properties (especially in scenarios where remote JMX is enabled), and 
> should
> provide better alternatives to the users.

A better alternative already exists today. Derby system level properties 
can be specified in derby.properties, none of these values are then set 
as JVM system properties, and thus they will not appear to any standard 
jmx bean.

Exposing these (or a security conscious subset of them) through Derby's 
SystemMBean is fine, though I'm not sure that's what is being proposed 
by the jmx changes. I.e. does SystemMbean just display the value of the 
jvm system property or the value that derby is using (set as a jvm 
system property or in derby.properties)?

Dan.