passwords in config files stored in plaintext

[Stuart Stent]

The credentials for database conenctions and the keystone authtoken are stored in plaintext within the nova.conf and apipaste config files.

These values should be encrypted. A scheme similar to /etc/shadow would be great.

[Russell Bryant (russellb)]

I think we should consider this a "hardening" request as opposed to a private vulnerability. Opinions from other VMT members?

[Michael Still (mikal)]

Agreed. We need to be congnizant when we do this that it makes deployment harder as well. These config files are meant to only be readable by the nova user, right?

[Russell Bryant (russellb)]

mikal: right

[Stuart Stent (stuart-stent)]

Even if it is only readable by the nova user (and root of course) it's still possible for someone to potentailly read that file and acquire the passwords to the database, giving them ALOT of access to that system.

At least if they are encrypted, even if they do manage to read it, it doesn't get them much.

[Matt Fischer (mfisch)]

I see this bug is old and Wishlisted so it may never get fixed, but I'd like to add that plaintext passwords are generally a no-no when the service account auth is managed by Corporate AD or LDAP. It may complicate some deployments but it would be nice to have a solution to this.

[Daniël W. Crompton (daniel-crompton)]

A shadow like password wouldn't be possible as it needs to be reversible.
And as it's reversible anybody with access to the file would be able to
reverse it with the encryption scheme. Making it security by obscurity.

This could probably best be solved with something like a pkcs7 key
exchange, although this would be a little more work.

D.
On Mar 4, 2014 10:35 AM, "Matt Fischer" <email address hidden> wrote:

> I see this bug is old and Wishlisted so it may never get fixed, but I'd
> like to add that plaintext passwords are generally a no-no when the
> service account auth is managed by Corporate AD or LDAP. It may
> complicate some deployments but it would be nice to have a solution to
> this.
>
> --
> You received this bug notification because you are a member of OpenStack
> Security Group, which is subscribed to OpenStack.
> https://bugs.launchpad.net/bugs/1158328
>
> Title:
> passwords in config files stored in plaintext
>
> Status in OpenStack Compute (Nova):
> Confirmed
>
> Bug description:
> The credentials for database conenctions and the keystone authtoken
> are stored in plaintext within the nova.conf and apipaste config
> files.
>
> These values should be encrypted. A scheme similar to /etc/shadow
> would be great.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nova/+bug/1158328/+subscriptions
>
> _______________________________________________
> Openstack-security mailing list
> <email address hidden>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>

[Adrian Otto (aotto)]

I see Barbican as the right tool for this job. The configuration file can get the secret identifier, and the secret itself can be stored in Barbican where it can be centrally fortified, access controlled, access logged, and could be revoked. The service would use an HTTPS request to retrieve the secret from its encrypted remote storage in Barbican on an as-needed basis.

--
Adrian

On Mar 4, 2014, at 2:01 AM, "Daniël W. Crompton" <<email address hidden><mailto:<email address hidden>>> wrote:

A shadow like password wouldn't be possible as it needs to be reversible. And as it's reversible anybody with access to the file would be able to reverse it with the encryption scheme. Making it security by obscurity.

This could probably best be solved with something like a pkcs7 key exchange, although this would be a little more work.

D.

On Mar 4, 2014 10:35 AM, "Matt Fischer" <<email address hidden><mailto:<email address hidden>>> wrote:
I see this bug is old and Wishlisted so it may never get fixed, but I'd
like to add that plaintext passwords are generally a no-no when the
service account auth is managed by Corporate AD or LDAP. It may
complicate some deployments but it would be nice to have a solution to
this.

--
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1158328

Title:
  passwords in config files stored in plaintext

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  The credentials for database conenctions and the keystone authtoken
  are stored in plaintext within the nova.conf and apipaste config
  files.

  These values should be encrypted. A scheme similar to /etc/shadow
  would be great.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1158328/+subscriptions

_______________________________________________
Openstack-security mailing list
<email address hidden><mailto:<email address hidden>>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
_______________________________________________
Openstack-security mailing list
<email address hidden><mailto:<email address hidden>>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

[Sean Dague (sdague)]

I feel like this is pretty strongly out of scope. Applications that need to talk to databases that require passwords need access to those passwords in plain text. While we could do obfuscation, it doesn't really address the issue, it just makes you think you addressed it. Honestly better to leave things clear so people rightly understand that a compromise of that file means all bets are off.

[Glenn Ferguson (glenn-ferguson)]

This issue should not be dismissed as out of scope or declared as Won't fix. If OpenStack wants enterprise adoption, this are the issues that will need to be addressed.
As a side note, It doesn't help to have comments such as "acquire the passwords to the database, giving them ALOT of access to that system" in the thread then later dismiss the issue. It is not uncommon for IT auditors to assess risk to a given deployment and to come across this exchange. For someone not familiar with the inner workings of OpenStack - this becomes a major red flag in the audit report.

Personally I would like to see this issue addressed in some fashion other than plain text.

[Daniel Berrange (berrange)]

With postgresql at least you can configure it with authenticate with GSSAPI+Kerberos at which point there is no need to use passwords at all. I'm not sure if MySQL has the same level of GSSAPI integration, but this is the kind of approach we need to take.

Use of any kind of password auth is the root cause flaw, regardless of whether Nova has the passwd in a plain text file. So we need to identify recommendations on how to configure Nova + databases, etc with out use of passwords at all.

[Jeremy Stanley (fungi)]

Agreed. Obfuscation or symmetric encryption of passwords does not actually solve anything either, and is ultimately no better than plain text under most circumstances. The actual solution to the issues raised here is to not use passwords at all. Hopefully "enterprise" auditors will encourage systems which don't use passwords rather than bandages over something we've agreed for decades is bad practice.

As for MySQL, 5.5.7 and later support pluggable authentication backends: http://dev.mysql.com/doc/refman/5.5/en/pluggable-authentication.html Perhaps this is something worth documenting in an upcoming revision of the security guide?

[Duncan Thomas (duncan-thomas)]

This affects cinder (and many other projects) - we'd welcome a good solution, though I've no idea what that might be

[John Griffith (john-griffith)]

My two cents: Agree with encrypting the password doesn't solve much.... using pluggable options to db auth is the right answer here IMO.

I don't believe this is a bug either, but a feature request. I am certainly not discounting the importance of this feature, I'm receiving this question more and more from customers in the field deploying OpenStack in their internal cloud environments. Maybe we can look at something in Kilo as a feature/enhancement.

[John Haller (john-haller)]

The only way to solve problems like this is through a dedicated unit to store a secret like a TPM on each server, and even that won't help if someone can log in to the server as a privileged user and use the dedicated unit to generate an access key. Using Barbican isn't the total solution, as to allow the machine to retrieve a secret from Barbican requires that the machine have a secret it can use to access Barbican. GSSAPI doesn't help, as it requires a token, not significantly different than a password, to be available or embedded in the program to start the exchange. However, it's probably best to delegate the problem to Barbican and store the Cinder secrets there. This would leave it up to Barbican to support hardware plugins to securely store secrets, as well as leaving it as an exercise for the reader to properly protect access to the hardware device. Otherwise, every service on each server is going to have to implement its own mechanism, and they will all be different.