Jack Repenning wrote:
> Recall: OS X Leopard just plain breaks the API that implements
> "--non-interactive" around access to the keychain. The original
> description was that this, therefore, breaks --non-interactive.
>
> However, it turns out that operations that use --non-interactive plus
> --username plus --password do succeed (never have to go to the
> keychain for creds anyway). Small yay.
>
> However however, this also means that such operations end up caching
> the creds into svn.simple/ in the classic way.
>
> It seems to me that this makes it a security bug. My reasoning:
> someone on OS X, having read the documentation, expects credentials to
> be stored in the very secure keychain. Through this bug, however,
> they are stored in the much less secure svn.simple/. If this poor
> user trusted our promise to do the safe thing (even verified it under
> Tiger), they do not expect their creds to be stored in the file
> system. This may seduce them into relaxing the file system
> protections in some way, exposing their password.
>
> My question for this list: does this constitute a security bug for
> Subversion?
>
> On the basis of the reasoning above, I marked my bug at Apple as a
> security issue. They have just notified me that they don't consider
> this a security issue. They didn't give me detailed reasoning on that
> decision, but I do admit that the chain that leads to a breach
> contains components other than those supplied by Apple, and even some
> user configuration acts. I am considering bumping the Subversion bug
> up to reflect the "security" concern.
I think it is a security issue. If Subversion was compiled with keychain
support, it should IMHO never try to store passwords outside the
keychain, regardless --(non-)interactive. Same goes for password
encryption on Windows, although AFAIK that never requires the user to
interactively enter a password.
I see two possible solutions here:
* Update our whole authn-provider-chain infrastructure so that an
authn plugin can tell the authn store code to stop walking the
chain -- effectively causing it to not store authentication info.
I think that would even make sense in the --non-interactive case.
o An alternative implementation of the above: each authn
provider could grow a flag that told the chain walker if it
was allowed to write or only to read auth info.
* A more Mac-specific solution would cause the keychain provider to
lie that it had stored the username and password, even if it in
fact didn't. This option seems like a bit of a wart, though.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-04 06:46:05 CET