Hi Neil and Thorsten,
Thanks for your feedback, as you know I am currently I the US at the
MySQL users conference and obviously a bit jet-lagged. I will work on
the feedback the week after when I am back in Germany.
Detlef
Neil Garthwaite wrote:
> Hi Detelf,
>
> To add to Thorsten's comments here are mine.
>
> usr/src/cmd/ha-services/gds-agents/PostgreSQL/functions.ksh
>
> - lines 1266/1309/1366/1511/1565, please consider that using "su -"
> you may invoke a profile that requests a prompt. Instead you could
> consider using "su <user> -c "env <var> command etc.)".
>
> - line 1299, I guess the 5 second timeout for ping is enough, although
> you may want to consider making this a user defined variable.
>
> usr/src/cmd/ha-services/gds-agents/PostgreSQL/functions_static.ksh
>
> - line 164, you're missing a ", this means that lines 166-89 will
> never get called.
>
> usr/src/cmd/ha-services/gds-agents/PostgreSQL/rolechg/functions.ksh
>
> - line 417 "su -"
>
> usr/src/cmd/ha-services/gds-agents/PostgreSQL/rolechg/resilver-step1.ksh
>
> - line 218, "can can"
> - line 236, "root root"
>
> usr/src/cmd/ha-services/gds-agents/PostgreSQL/pgs_register.ksh
>
> - lines 88/226/382/386 you want to quote the text
>
> usr/src/cmd/ha-services/gds-agents/PostgreSQL/pgs_smf_register.ksh
>
> - line 69, has a 2006 copyright
>
> Regards
> Neil
>
> On 11 Apr 2008, at 14:04, Thorsten Frueauf wrote:
>
>> Hi Detlef et al,
>>
>> here are my comments for you updated webrev:
>>
>> - general, you should verify the indention for scds_syslog messages.
>> The following line of scds_syslog should have one more level of
>> indention, if that is part of the message or args, like
>>
>> 417 scds_syslog -p daemon.err -t
>> $(syslog_tag) -m \
>> 418 "Function: validate: The %s
>> variable is not set, but it is required" \
>> 419 "USER"
>>
>> should really look like
>>
>> 417 scds_syslog -p daemon.err -t
>> $(syslog_tag) -m \
>> 418 "Function: validate: The %s
>> variable is not set, but it is required" \
>> 419 "USER"
>>
>> The source files sometimes have that right, many times not. Make sure
>> all new
>> scds_syslog messages you add follow that rule - and all new code
>> within the
>> rolechg/* as well.
>>
>>
>> - usr/src/cmd/ha-services/gds-agents/PostgreSQL/control_pgs.ksh
>>
>> * general, still inconsistent use of rm vs ${RM}
>>
>>
>> - usr/src/cmd/ha-services/gds-agents/PostgreSQL/functions.ksh
>> - line 1260, use "${CP} -p" instead of just "${CP}", that
>> will ensure that the file is not created with the current umask
>> of user root.
>>
>> - line 1261, can be removed if you use "${CP} -p" in line 1260
>>
>> - line 1272, why don't you need the chown from line 1260 before
>> this call?
>>
>>
>> - usr/src/cmd/ha-services/gds-agents/PostgreSQL/functions_static
>> - line 535, typo fuction -> function
>>
>>
>> - usr/src/cmd/ha-services/gds-agents/PostgreSQL/pgs_register.ksh
>> - line 24, copyright needs to be 2008
>>
>> - the code line 81-103 and 219-237 seems to do the exact same
>> thing.
>> Could you deduplicate it by calling it in a generic portion that
>> is true for global and non-global zone usage?
>>
>> - line 383, displaying the passphrase on the screen is not a secure
>> way to get the passphrase from the user. Disable echo to the
>> tty and ask for the passphrase twice, compare both inputs and
>> only
>> succeed if they are identical. The passphrase must not be
>> displayed
>> on the screen.
>>
>>
>> -
>> usr/src/cmd/ha-services/gds-agents/PostgreSQL/rolechg/control_rolechg.ksh
>>
>> - general - since this is new code, make sure every command you
>> call has the full path prefixed. e.g. line 93, 134, 158 call
>> just rm
>> instead of /bin/rm.
>> Note that e.g. Indiana has no longer /bin or /usr/bin as first in
>> $PATH - so you might experience undesired effects. Same is true
>> if PATH for thr root user is changed.
>>
>>
>> - usr/src/cmd/ha-services/gds-agents/PostgreSQL/rolechg/functions.ksh
>> usr/src/cmd/ha-services/gds-agents/PostgreSQL/rolechg/resilver-step1.ksh
>> usr/src/cmd/ha-services/gds-agents/PostgreSQL/rolechg/resilver-step2.ksh
>> usr/src/cmd/ha-services/gds-agents/PostgreSQL/rolechg/rolechg_config.ksh
>> - line 27 or 28, ident string is not expanded, while the ident
>> string
>> on some other new files are. Make sure this is correct.
>>
>> -
>> usr/src/cmd/ha-services/gds-agents/PostgreSQL/rolechg/resilver-step1.ksh
>> usr/src/cmd/ha-services/gds-agents/PostgreSQL/rolechg/resilver-step2.ksh
>> - generic, why do you check "if [ -d /etc/cluster ]"?
>> would checking with "clinfo" for cluster mode not being better?
>>
>> - generic, I assume it is important that resilver-step2.ksh is
>> only called after resilver-step1.ksh has been run.
>> Therefor I suggest resilver-step1.ksh creates a file within
>> /tmp or /var/tmp which resilver-step2.ksh looks for, only
>> if it exists it proceeds, otherwise it aborts or warns.
>> resilver-step2.ksh would then remove that file after a successful
>> run.
>>
>> -
>> usr/src/cmd/ha-services/gds-agents/PostgreSQL/rolechg/rolechg_register.ksh
>>
>> - line 61, I know currently there is nothing to do for a probe,
>> but I would recommend to call /usr/bin/true from the
>> control_rolechg
>> command and add a switch for the probe option. That way, if for
>> some reason you find out it would be good to do something during
>> probe, this can be introduced via patch without requiring the
>> user
>> to re-register.
>>
>> - line 136, either use ${CP} (which you need to setup), or use
>> /bin/cp
>>
>> - line 152, same as line 136, this time either ${RM} or /bin/rm
>>
>> Greets
>> Thorsten
>>
>>
>> Detlef Ulherr wrote:
>>> Hi Thorsten et all
>>>
>>> The changes are made and available in the current webrev under
>>> http://cr.opensolaris.org/~ulherr/pgshotstandby
>>>
>>> Comments are appreciated
>>>
>>> Detlef
>>>
>>> Detlef Ulherr wrote:
>>>> Hi Thorsten,
>>>>
>>>> I will combine Tims and your suggestion.
>>>>
>>>> Detlef
>>>>
>>>> Thorsten Frueauf wrote:
>>>>
>>>>> Hi Detlef, Tim et al,
>>>>>
>>>>> I would agree if we are in an interactive user session. We are not.
>>>>>
>>>>> Said customers likely also have in their policy that a password or
>>>>> passphrase must not be written down or stored in cleartext. Now what?
>>>>>
>>>>> Anyway, I gave my review comment and reasons as of why I would
>>>>> recommend against such an option completely.
>>>>>
>>>>> I hope others add their own or other potential customer perspectives.
>>>>>
>>>>> In any case, the existing code does not satisfy basic security
>>>>> concerns. I would also recommend against an variable option for the
>>>>> passphrases within pgs_config for the reasons I cited way below. If
>>>>> you still want to use such a passphrase, ask for it during
>>>>> registration and store it right away in the destination and make sure
>>>>> the permission and owner is set _before_ you write it in there (not
>>>>> after).
>>>>>
>>>>> Greets
>>>>> Thorsten
>>>>>
>>>>> Detlef Ulherr wrote:
>>>>>
>>>>>> Hi Thorsten, Tim et all
>>>>>>
>>>>>> I second Tims position, if you search in google how to set up ssh
>>>>>> you
>>>>>> find the advice "never go without a passphrase" So it is likely
>>>>>> that we
>>>>>> hit the scenario where a customer does not allow the passwordless
>>>>>> login
>>>>>> without a passphrase.
>>>>>>
>>>>>> My former employer (names do not belong in public discussions)
>>>>>> was one
>>>>>> of these. The existence of the passphrases was checked and
>>>>>> enforced at
>>>>>> audits. To pass the audit without a passphrase it needed a very good
>>>>>> reason.
>>>>>>
>>>>>> Detlef
>>>>>>
>>>>>> Tim Read - Staff Engineer Solaris Availability Engineering wrote:
>>>>>>
>>>>>>> Thorsten,
>>>>>>>
>>>>>>> I agree, security by obscurity won't work. But if customer have a
>>>>>>> policy of requiring passphrases, this module will not be able to
>>>>>>> handle that situation. We cannot insist that users change their
>>>>>>> security standards.
>>>>>>>
>>>>>>> I think we could make it quite difficult for the intermediate file
>>>>>>> to be intercepted. It all depends on the scheduling between:
>>>>>>>
>>>>>>> root# echo "password" > cleartext_password
>>>>>>> root# chmod 400 cleartext_password
>>>>>>> [A]
>>>>>>> root# chown postgres cleartext_password
>>>>>>> root# /bin/su postgres -c "( /bin/cat cleartext_password; \
>>>>>>> /bin/rm cleartext_password) | some command"
>>>>>>> [B]
>>>>>>>
>>>>>>> It's not inconceivable that a tight loop could pick this up between
>>>>>>> [A] and [B], though the sudden spike in CPU usage might give the
>>>>>>> perpetrator away.
>>>>>>>
>>>>>>> Away, I don't think adding this feature makes it any worse, but it
>>>>>>> does allow us to comply with customers requirements here should
>>>>>>> they
>>>>>>> have one.
>>>>>>>
>>>>>>> Since this is an open process, we should see what others think,
>>>>>>> after all, this is about meeting user requirements.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Tim
>>>>>>> ---
>>>>>>>
>>>>>>>
>>>>>>> Thorsten Frueauf wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hi Tim et al,
>>>>>>>>
>>>>>>>> the current implementation in the webrev is surly different from
>>>>>>>> what you describe below.
>>>>>>>>
>>>>>>>> But anyway, security by obscurity is not going to work, since the
>>>>>>>> agent code is a) open source and b) available for anyone local to
>>>>>>>> the system within /opt/SUNWscPostgreSQL/*.
>>>>>>>>
>>>>>>>> Thus if you assume a local compromised system it would be an easy
>>>>>>>> task to now also intercept the moment where the password file is
>>>>>>>> made available.
>>>>>>>>
>>>>>>>> The passwordless access via ssh using authorized keys is a common
>>>>>>>> used technique. If this solution requires ssh in that form I am
>>>>>>>> not
>>>>>>>> sure what other option there is for the user. Adding the ssh
>>>>>>>> passphrase does not increase security in this case - since we are
>>>>>>>> not interactive with a user.
>>>>>>>>
>>>>>>>> I did not write the best practice documents I referred to, but if
>>>>>>>> /usr/ucb/ps works in the way described when assuming that the
>>>>>>>> local
>>>>>>>> PostgreSQL user is breached, this is all you need, since the ssh
>>>>>>>> agent is setup as this user.
>>>>>>>>
>>>>>>>> In summary I am not sure of the option to store the passphrase in
>>>>>>>> cleartext adds any further to the security, but it may pretend a
>>>>>>>> level of security that is not there.
>>>>>>>>
>>>>>>>> Greets
>>>>>>>> Thorsten
>>>>>>>>
>>>>>>>> Tim Read - Staff Engineer Solaris Availability Engineering wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Thorsten,
>>>>>>>>>
>>>>>>>>> May be I should re-check the code that Detlef has as I
>>>>>>>>> recommended
>>>>>>>>> that he use passphrases. My original idea was that the passphrase
>>>>>>>>> would be transiently made available to the Postgres user account
>>>>>>>>> by some controlling root script that wrote it into a Postgres
>>>>>>>>> owned (chmod 400) file. The Postgres user, probably via su, would
>>>>>>>>> then consume that passphrase and then delete the file. Thus the
>>>>>>>>> file would be present for no more than a few seconds, if that.
>>>>>>>>>
>>>>>>>>> The (limited?) advantage is that if the Postgres has been
>>>>>>>>> compromised locally, it doesn't mean that the account is
>>>>>>>>> compromised remotely unless they know of this mechanism and/or
>>>>>>>>> manage to intercept the file.
>>>>>>>>>
>>>>>>>>> I believe the link below has an inaccuracy: /usr/ucb/ps -aeww
>>>>>>>>> command does not expose the environment of other users to each
>>>>>>>>> other. Only root can view anyone's environment and individual
>>>>>>>>> users can only see theirs. This is exactly what you would expect.
>>>>>>>>> May be this has changed since the document was written.
>>>>>>>>>
>>>>>>>>> In summary, I don't think all users are comfortable with accounts
>>>>>>>>> having passwordless ssh. We should not force this requirement on
>>>>>>>>> them.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Tim
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thorsten Frueauf wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> The passphrase is optional, and the code works perfect with the
>>>>>>>>>>> authorized keys alone. so it is up to the user to configure the
>>>>>>>>>>> passphrase. The passphrase was added to the code upon feedback
>>>>>>>>>>> as an
>>>>>>>>>>> otional configuration. The administrator who prefers to go with
>>>>>>>>>>> authorized keys and passwordless login between the PostgreSQL
>>>>>>>>>>> users is
>>>>>>>>>>> free to do so. if he wants to add a passphrase to his keys he
>>>>>>>>>>> can do so
>>>>>>>>>>> as well. so it is all about choice
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Maybe Tim or you can explain as of what additional security the
>>>>>>>>>> passphrase is supposed to offer, if the passphrase is stored in
>>>>>>>>>> clear text readable by root and the PostgreSQL user. How is that
>>>>>>>>>> better from a passwordless access realized through the
>>>>>>>>>> authorized
>>>>>>>>>> keys for the PostgreSQL user?
>>>>>>>>>>
>>>>>>>>>> The authorized key mechanism already needs access to the
>>>>>>>>>> PostgreSQL user .ssh settings. Only then the passwordless access
>>>>>>>>>> will work.
>>>>>>>>>>
>>>>>>>>>> Now if already the PostgreSQL user got breached, when using the
>>>>>>>>>> ssh passphrase, it then is also available to the one that
>>>>>>>>>> breached the PostgreSQL user. To me there is no additional
>>>>>>>>>> security gain, but being able to use the passphrase adds an
>>>>>>>>>> additional concern.
>>>>>>>>>>
>>>>>>>>>> I would strongly recommend to not use this new implementation
>>>>>>>>>> you
>>>>>>>>>> added for the ssh passphrase.
>>>>>>>>>>
>>>>>>>>>> Maybe have a look at
>>>>>>>>>> http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/
>>>>>>>>>>
>>>>>>>>>> and
>>>>>>>>>> http://opensolaris.org/os/community/arc/bestpractices/passwords-files/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The best way is really to avoid that headache completely.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> I see the problem here, that the passphrase is readable at
>>>>>>>>>>> least
>>>>>>>>>>> for
>>>>>>>>>>> root or the PostgreSQL user. But every simple encryption is
>>>>>>>>>>> easy
>>>>>>>>>>> breakable, and does not add very much as well.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Thats why I recommend to not introduce such a mechanism. It is
>>>>>>>>>> not necessary and does not add security to the authorized key
>>>>>>>>>> option.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> I will restrict the permissions of the parameter file to the
>>>>>>>>>>> PostgreSQL.
>>>>>>>>>>> It has to be the PostgreSQL user sorry, otherwise I then would
>>>>>>>>>>> require a
>>>>>>>>>>> passwordless login for the root user which I really want to
>>>>>>>>>>> avoid.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Will send my comments for the missing files as soon as I can.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> Since the default permission for the pgs_config is 644, I would
>>>>>>>>>> assume that any user making a copy will inherit this permission.
>>>>>>>>>> And for registration the passphrase will be readable in there.
>>>>>>>>>> And the copy will likely stay in mode 644 as well.
>>>>>>>>>>
>>>>>>>>>> Introducing the ssh passphrase adds more headache than you want
>>>>>>>>>> while I don't see the value add.
>>>>>>>>>>
>>>>>>>>>> Reading the cited comments from Tim (I did not see his original
>>>>>>>>>> mail) I can also not see where he asked for a ssh passphrase
>>>>>>>>>> implementation.
>>>>>>>>>>
>>>>>>>>>> I am not sure why he says "Having passwordless login is probably
>>>>>>>>>> not a good idea." - maybe we can hear the real concern for this
>>>>>>>>>> scenario?
>>>>>>>>>>
>>>>>>>>>> Greets
>>>>>>>>>> Thorsten
>>
>> --~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> Sitz der Gesellschaft:
>> Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
>> Amtsgericht Muenchen: HRB 161028
>> Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
>> Vorsitzender des Aufsichtsrates: Martin Haering
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> _______________________________________________
>> ha-clusters-discuss mailing list
>> ha-clusters-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
>
--
*****************************************************************************
Detlef Ulherr
Staff Engineer Tel: (++49 6103) 752-248
Availability Engineering Fax: (++49 6103) 752-167
Sun Microsystems GmbH
Amperestra?e 6 mailto:detlef.ulherr at sun.com
63225 Langen http://www.sun.de/
*****************************************************************************
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551
Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering
*****************************************************************************
