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