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
>
--
Tim Read
Staff Engineer
Solaris Cluster Engineering
Sun Microsystems Ltd
Springfield
Linlithgow
EH49 7LR
Phone: +44 (0)1506 672 684
Mobile: +44 (0)7802 212 137
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
