Some thoughts.
On Mon, Aug 6, 2012 at 2:42 AM, Christian Mueller <mcrmc...@gmail.com>wrote:
> I think there are some important facts I want to point out.
>
> 1)
>
> 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.
>
>
> 2)
>
> 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@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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
