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 >>>>>>> > > -- ***************************************************************************** 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 *****************************************************************************
