[Geoserver-devel] Security considerations for 2.2.x series

GeoServer GeoServer Developer
1

I think there are some important facts I want to point out.

Upgrading a secured geoserver to 2.2 series in a production environment opens a security leak. At first startup, the security directory is migrated, so far, so good. Starting with version 2.2.0 there is a new super user called “root” with administrative privileges. The password is “geoserver”. As a consequence, after upgrading, anybody can log in as an administrator.

It is absolutely necessary to do a “master password change” after upgrading (in a secured production environment). Perhaps we should add a paragraph in upper case letters to the release notes ?

For a fresh installation of geoserver 2.2.x, I assume the security directory is this one
https://github.com/geoserver/geoserver/tree/master/data/release/security

This directory is not migrated. The migration would take a place at first geoserver start. I am asking my self if it would be better to migrate once and push the migrated security directory to github.

Next, it is not necessary to have an “admin” user because we have the “root” user. The advantage of having no “admin” user is to force people to do a master password change, the disadvantage is that the “admin” user is referenced in the documentation very often.

Please remember, the master password used by “root” is also used to protect the new geoserver key store. This password is the Achilles tendon of the system.

Opinons ?

2

Some thoughts.

On Mon, Aug 6, 2012 at 2:42 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

I think there are some important facts I want to point out.

Upgrading a secured geoserver to 2.2 series in a production environment opens a security leak. At first startup, the security directory is migrated, so far, so good. Starting with version 2.2.0 there is a new super user called “root” with administrative privileges. The password is “geoserver”. As a consequence, after upgrading, anybody can log in as an administrator.

It is absolutely necessary to do a “master password change” after upgrading (in a secured production environment). Perhaps we should add a paragraph in upper case letters to the release notes ?

What if on migration we generated a random password for the root account. And also provide the plain text version of it (perhaps in a supplementary file next to the master password file). Anyways, the idea would be for the admin doing the upgrade to check this file, and change the master password immediately. It would be more secure than a default password since you would really need access to the server file system to get at it.

Regardless, whatever we choose will have to be clearly documented and should be made clear in any blog posts or releases notes.

For a fresh installation of geoserver 2.2.x, I assume the security directory is this one
https://github.com/geoserver/geoserver/tree/master/data/release/security

This directory is not migrated. The migration would take a place at first geoserver start. I am asking my self if it would be better to migrate once and push the migrated security directory to github.

Yeah, in general we have always lagged behind a bit in terms of the configurations we store in version control. One of the nice things about this is that it forces the devs to constantly deal with backward compatibility. Given that the first bit of a new stable release tends to be a bit “unstable” it seems safer to keep the official configuration lagging behind a bit. But eventually yes I think we should change it.

Next, it is not necessary to have an “admin” user because we have the “root” user. The advantage of having no “admin” user is to force people to do a master password change, the disadvantage is that the “admin” user is referenced in the documentation very often.

Well I do think they serve different purposes as the admin account is used for day to day administration and the root account is really just a backdoor in cases where something has really been fowled up…

Please remember, the master password used by “root” is also used to protect the new geoserver key store. This password is the Achilles tendon of the system.

Opinons ?

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

3

On Mon, Aug 6, 2012 at 7:14 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

What if on migration we generated a random password for the root account.
And also provide the plain text version of it (perhaps in a supplementary
file next to the master password file). Anyways, the idea would be for the
admin doing the upgrade to check this file, and change the master password
immediately. It would be more secure than a default password since you would
really need access to the server file system to get at it.

Regardless, whatever we choose will have to be clearly documented and should
be made clear in any blog posts or releases notes.

How about just having the master password be equal to the "admin" user password,
if that user is present? Would make for a reasonable upgrade for most people.

Yeah, in general we have always lagged behind a bit in terms of the
configurations we store in version control. One of the nice things about
this is that it forces the devs to constantly deal with backward
compatibility. Given that the first bit of a new stable release tends to be
a bit "unstable" it seems safer to keep the official configuration lagging
behind a bit. But eventually yes I think we should change it.

Agreed

Next, it is not necessary to have an "admin" user because we have the
"root" user. The advantage of having no "admin" user is to force people to
do a master password change, the disadvantage is that the "admin" user is
referenced in the documentation very often.

Well I do think they serve different purposes as the admin account is used
for day to day administration and the root account is really just a backdoor
in cases where something has really been fowled up...

Agreed

Please remember, the master password used by "root" is also used to
protect the new geoserver key store. This password is the Achilles tendon of
the system.

Opinons ?

Ouch, let's not talk about Achille's tendons, I already teared apart one! :-p

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

4

On Mon, Aug 6, 2012 at 11:21 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Aug 6, 2012 at 7:14 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

What if on migration we generated a random password for the root account.
And also provide the plain text version of it (perhaps in a supplementary
file next to the master password file). Anyways, the idea would be for the
admin doing the upgrade to check this file, and change the master password
immediately. It would be more secure than a default password since you would
really need access to the server file system to get at it.

Regardless, whatever we choose will have to be clearly documented and should
be made clear in any blog posts or releases notes.

How about just having the master password be equal to the “admin” user password,
if that user is present? Would make for a reasonable upgrade for most people.

Agreed, this would make the most sense and I am not 100% sure why we are not doing this already since on migration the admin password is available in plain text so no need to do any decryption or anything. I think it has to do with the startup sequence in which we need to basically create the master password as the first thing before we do any of the other migration. But still we should be able to just read the old password regardless before creating the master paswd config.

@Christian: Do you see any problem with that?

Yeah, in general we have always lagged behind a bit in terms of the
configurations we store in version control. One of the nice things about
this is that it forces the devs to constantly deal with backward
compatibility. Given that the first bit of a new stable release tends to be
a bit “unstable” it seems safer to keep the official configuration lagging
behind a bit. But eventually yes I think we should change it.

Agreed

Next, it is not necessary to have an “admin” user because we have the
“root” user. The advantage of having no “admin” user is to force people to
do a master password change, the disadvantage is that the “admin” user is
referenced in the documentation very often.

Well I do think they serve different purposes as the admin account is used
for day to day administration and the root account is really just a backdoor
in cases where something has really been fowled up…

Agreed

Please remember, the master password used by “root” is also used to
protect the new geoserver key store. This password is the Achilles tendon of
the system.

Opinons ?

Ouch, let’s not talk about Achille’s tendons, I already teared apart one! :-p

Cheers
Andrea

–

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

5

+1. Much safer than "geoserver".

On 07/08/12 01:21, Andrea Aime wrote:

How about just having the master password be equal to the "admin" user password,
if that user is present? Would make for a reasonable upgrade for most people.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

6

This should be a last resort as it would effectively lock the account for those deploying GeoServer in a managed environment in which they do not have root access. I still think it is better than a default password, so perhaps this should be done if there was no admin account before the upgrade?

On 07/08/12 01:14, Justin Deoliveira wrote:

What if on migration we generated a random password for the root account.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

7

Now I am unsure, should I prepare a migrated security directory for 2.2.x and 2.3.x or not ???

2012/8/7 Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>

This should be a last resort as it would effectively lock the account for those deploying GeoServer in a managed environment in which they do not have root access. I still think it is better than a default password, so perhaps this should be done if there was no admin account before the upgrade?

On 07/08/12 01:14, Justin Deoliveira wrote:

What if on migration we generated a random password for the root account.

–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

8

On Tue, Aug 7, 2012 at 3:36 PM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

Now I am unsure, should I prepare a migrated security directory for 2.2.x and 2.3.x or not ???

I would put it on 2.3.x, and backport once we are satisfied the automatic upgrade
is doing the right thing

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

9

On Tue, Aug 7, 2012 at 7:49 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Aug 7, 2012 at 3:36 PM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

Now I am unsure, should I prepare a migrated security directory for 2.2.x and 2.3.x or not ???

I would put it on 2.3.x, and backport once we are satisfied the automatic upgrade
is doing the right thing

Christian. To clarify we are not changing this to mitigate the root account security hole, the plan is to make the root account password the same as the admin account password. Falling back on a random password (saved out in plain text) if the admin account does not exist.

I wanted to hear from you on your thoughts about this?

As for the data directory change i would actually just leave it as is for now. But no strong objection to changing it on master.

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

10

I got some additional input from Ian. To summarize:

  1. Check for a user called admin and use this password as master password candidate. If the password is “geoserver” continue with 3), otherwise write a corresponding message to the log file and stop.

  2. If there is no user called admin, check for a user having ROLE_ADMINISTRATOR and use this password as a candidate. If the password is “geoserver”, continue with 3) otherwise write a corresponding message to the log file and stop.

  3. Generate a password with 8 characters. Store the password in a file masterpw.generated and write a message to the log file.

This would assure that the migration never results in a master password “geoserver”. If we want to go this way, I would not check in a migrated security directory. Each geoserver installation should have its individual master password.

Opinions ?

2012/8/7 Justin Deoliveira <jdeolive@anonymised.com>

On Tue, Aug 7, 2012 at 7:49 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Aug 7, 2012 at 3:36 PM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

Now I am unsure, should I prepare a migrated security directory for 2.2.x and 2.3.x or not ???

I would put it on 2.3.x, and backport once we are satisfied the automatic upgrade
is doing the right thing

Christian. To clarify we are not changing this to mitigate the root account security hole, the plan is to make the root account password the same as the admin account password. Falling back on a random password (saved out in plain text) if the admin account does not exist.

I wanted to hear from you on your thoughts about this?

As for the data directory change i would actually just leave it as is for now. But no strong objection to changing it on master.

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

11

Sounds good to me. +1

On Tue, Aug 7, 2012 at 8:55 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

I got some additional input from Ian. To summarize:

  1. Check for a user called admin and use this password as master password candidate. If the password is “geoserver” continue with 3), otherwise write a corresponding message to the log file and stop.

  2. If there is no user called admin, check for a user having ROLE_ADMINISTRATOR and use this password as a candidate. If the password is “geoserver”, continue with 3) otherwise write a corresponding message to the log file and stop.

  3. Generate a password with 8 characters. Store the password in a file masterpw.generated and write a message to the log file.

This would assure that the migration never results in a master password “geoserver”. If we want to go this way, I would not check in a migrated security directory. Each geoserver installation should have its individual master password.

Opinions ?

2012/8/7 Justin Deoliveira <jdeolive@anonymised.com>

On Tue, Aug 7, 2012 at 7:49 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Aug 7, 2012 at 3:36 PM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

Now I am unsure, should I prepare a migrated security directory for 2.2.x and 2.3.x or not ???

I would put it on 2.3.x, and backport once we are satisfied the automatic upgrade
is doing the right thing

Christian. To clarify we are not changing this to mitigate the root account security hole, the plan is to make the root account password the same as the admin account password. Falling back on a random password (saved out in plain text) if the admin account does not exist.

I wanted to hear from you on your thoughts about this?

As for the data directory change i would actually just leave it as is for now. But no strong objection to changing it on master.

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

12

Opinions ?

An excellent suggestion.

Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents.

13

I solved https://jira.codehaus.org/browse/GEOS-5256 on 2.2.x and 2.3.x. The detailed concept is described in the user guide, section “upgrading”.

Some thoughts about 2.3.x. I would like to have a migrated security directory for fresh installations. The default master password would be “geoserver”. During startup, the security subsystem tries to open the key store using “geoserver”. If this is possible, the subsystem generates a new master password and executes a master password change and creates a file containing the new master password.

Opinions

2012/8/7 Phil Scadden <p.scadden@anonymised.com>

Opinions ?
An excellent suggestion.

Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents.

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

14

On Sun, Aug 12, 2012 at 9:03 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

I solved https://jira.codehaus.org/browse/GEOS-5256 on 2.2.x and 2.3.x. The detailed concept is described in the user guide, section “upgrading”.

Some thoughts about 2.3.x. I would like to have a migrated security directory for fresh installations. The default master password would be “geoserver”. During startup, the security subsystem tries to open the key store using “geoserver”. If this is possible, the subsystem generates a new master password and executes a master password change and creates a file containing the new master password.

I’m + 1on having a migrated security directory on trunk.

At the same time, I’m not sure about making changes to the default password if we find it’s “geoserver”. We are already warning the
admin that the password is unsafe, but imho we should not replace the admin will/judgement about changing it, it
should not be something automatic

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

15

On Sun, Aug 12, 2012 at 9:03 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

I solved https://jira.codehaus.org/browse/GEOS-5256 on 2.2.x and 2.3.x. The detailed concept is described in the user guide, section “upgrading”.

Some thoughts about 2.3.x. I would like to have a migrated security directory for fresh installations. The default master password would be “geoserver”. During startup, the security subsystem tries to open the key store using “geoserver”. If this is possible, the subsystem generates a new master password and executes a master password change and creates a file containing the new master password.

I’m + 1on having a migrated security directory on trunk.

At the same time, I’m not sure about making changes to the default password if we find it’s “geoserver”. We are already warning the
admin that the password is unsafe, but imho we should not replace the admin will/judgement about changing it, it
should not be something automatic

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

16

Btw, it is not a good idea to have a keystore in the migrated security directory. The default user group service uses encryption for passwords. The key for encryption is stored in the key store. With a default keystore, each geoserver installation would use the same secret key → this is the same as doing no encryption at all. The key store should be generated at first time boot to ensure an individual encryption key for user passwords. After the key is generated, we have to add the user “admin” with “password” geoserver to the default user group service.

About the key store password “geoserver”. I fear some confusion for our users. We have a user admin with password geoserver and there is second password (master password == key store password ) with the default value “geoserver”.

Your opinion ?

2012/8/13 Andrea Aime <andrea.aime@anonymised.com>

On Sun, Aug 12, 2012 at 9:03 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

I solved https://jira.codehaus.org/browse/GEOS-5256 on 2.2.x and 2.3.x. The detailed concept is described in the user guide, section “upgrading”.

Some thoughts about 2.3.x. I would like to have a migrated security directory for fresh installations. The default master password would be “geoserver”. During startup, the security subsystem tries to open the key store using “geoserver”. If this is possible, the subsystem generates a new master password and executes a master password change and creates a file containing the new master password.

I’m + 1on having a migrated security directory on trunk.

At the same time, I’m not sure about making changes to the default password if we find it’s “geoserver”. We are already warning the
admin that the password is unsafe, but imho we should not replace the admin will/judgement about changing it, it
should not be something automatic

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

17

On Mon, Aug 13, 2012 at 8:27 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

Btw, it is not a good idea to have a keystore in the migrated security directory. The default user group service uses encryption for passwords. The key for encryption is stored in the key store. With a default keystore, each geoserver installation would use the same secret key → this is the same as doing no encryption at all. The key store should be generated at first time boot to ensure an individual encryption key for user passwords. After the key is generated, we have to add the user “admin” with “password” geoserver to the default user group service.

Right… what will happen now if a security config is migrated but no keystore exists? Anyways should be easy enough to create on demand.

About the key store password “geoserver”. I fear some confusion for our users. We have a user admin with password geoserver and there is second password (master password == key store password ) with the default value “geoserver”.

Your opinion ?

Not sure what you are asking here…

2012/8/13 Andrea Aime <andrea.aime@anonymised.com>

On Sun, Aug 12, 2012 at 9:03 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

I solved https://jira.codehaus.org/browse/GEOS-5256 on 2.2.x and 2.3.x. The detailed concept is described in the user guide, section “upgrading”.

Some thoughts about 2.3.x. I would like to have a migrated security directory for fresh installations. The default master password would be “geoserver”. During startup, the security subsystem tries to open the key store using “geoserver”. If this is possible, the subsystem generates a new master password and executes a master password change and creates a file containing the new master password.

I’m + 1on having a migrated security directory on trunk.

At the same time, I’m not sure about making changes to the default password if we find it’s “geoserver”. We are already warning the
admin that the password is unsafe, but imho we should not replace the admin will/judgement about changing it, it
should not be something automatic

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

18

Please take a look at

http://docs.geoserver.org/stable/en/user/installation/upgrade.html

section “Obtaining a master password”.

This algorithm works for upgrading from versions < 2.2 and for fresh installations of 2.2.x. Since we have no migrated security directory in 2.2.x, a fresh installation will also trigger the security migration and the result is always a randomly generated master password of 8 characters stored in masterpw.info.

For versions 2.3.x, fresh installations will use an already migrated security directory. To be consistent, I would like to generate a random master password of 8 chars and store it into masterpw.info.

I dislike the idea of having a master password “geoserver”. This password should be reserved for the standard “admin” user.

Hope my idea becomes clearer :slight_smile:

2012/8/13 Justin Deoliveira <jdeolive@anonymised.com>

On Mon, Aug 13, 2012 at 8:27 AM, Christian Mueller <mcrmcr21@anonymised.com403…> wrote:

Btw, it is not a good idea to have a keystore in the migrated security directory. The default user group service uses encryption for passwords. The key for encryption is stored in the key store. With a default keystore, each geoserver installation would use the same secret key → this is the same as doing no encryption at all. The key store should be generated at first time boot to ensure an individual encryption key for user passwords. After the key is generated, we have to add the user “admin” with “password” geoserver to the default user group service.

Right… what will happen now if a security config is migrated but no keystore exists? Anyways should be easy enough to create on demand.

About the key store password “geoserver”. I fear some confusion for our users. We have a user admin with password geoserver and there is second password (master password == key store password ) with the default value “geoserver”.

Your opinion ?

Not sure what you are asking here…

2012/8/13 Andrea Aime <andrea.aime@anonymised.com>

On Sun, Aug 12, 2012 at 9:03 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

I solved https://jira.codehaus.org/browse/GEOS-5256 on 2.2.x and 2.3.x. The detailed concept is described in the user guide, section “upgrading”.

Some thoughts about 2.3.x. I would like to have a migrated security directory for fresh installations. The default master password would be “geoserver”. During startup, the security subsystem tries to open the key store using “geoserver”. If this is possible, the subsystem generates a new master password and executes a master password change and creates a file containing the new master password.

I’m + 1on having a migrated security directory on trunk.

At the same time, I’m not sure about making changes to the default password if we find it’s “geoserver”. We are already warning the
admin that the password is unsafe, but imho we should not replace the admin will/judgement about changing it, it
should not be something automatic

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

19

On Tue, Aug 14, 2012 at 10:35 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

Please take a look at

http://docs.geoserver.org/stable/en/user/installation/upgrade.html

section “Obtaining a master password”.

This algorithm works for upgrading from versions < 2.2 and for fresh installations of 2.2.x. Since we have no migrated security directory in 2.2.x, a fresh installation will also trigger the security migration and the result is always a randomly generated master password of 8 characters stored in masterpw.info.

For versions 2.3.x, fresh installations will use an already migrated security directory. To be consistent, I would like to generate a random master password of 8 chars and store it into masterpw.info.

I dislike the idea of having a master password “geoserver”. This password should be reserved for the standard “admin” user.

Hope my idea becomes clearer :slight_smile:

Hmm… as an administrator I would not be happy about software generating a password on my back… but at the very least, if
it does, it should tell the administrator it did so by providing some feedback in the UI until that file is removed
(don’t expect the admins to read the logs line by line)

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

20

Good idea, some feedback on the GUI will not be a major problem. I am waiting for Justin´s opinion and hope to finish this issue this week.

2012/8/14 Andrea Aime <andrea.aime@anonymised.com…>

On Tue, Aug 14, 2012 at 10:35 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

Please take a look at

http://docs.geoserver.org/stable/en/user/installation/upgrade.html

section “Obtaining a master password”.

This algorithm works for upgrading from versions < 2.2 and for fresh installations of 2.2.x. Since we have no migrated security directory in 2.2.x, a fresh installation will also trigger the security migration and the result is always a randomly generated master password of 8 characters stored in masterpw.info.

For versions 2.3.x, fresh installations will use an already migrated security directory. To be consistent, I would like to generate a random master password of 8 chars and store it into masterpw.info.

I dislike the idea of having a master password “geoserver”. This password should be reserved for the standard “admin” user.

Hope my idea becomes clearer :slight_smile:

Hmm… as an administrator I would not be happy about software generating a password on my back… but at the very least, if
it does, it should tell the administrator it did so by providing some feedback in the UI until that file is removed
(don’t expect the admins to read the logs line by line)

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it