Skip to content

pam modules for MySQL: What is wrong with these people?

Percona just released their MySQL PAM Authentication insanity, just as Oracle did before, for MySQL 5.5 and MariaDB is no better.

The Oracle module requires a module to be loaded into your client, which is done automatically if the module is present and the server supports PAM auth. The module is called ominously "mysql_clear_password" and does what it says on the tin: Your database server access password is henceforth sent from the client to the server in clear, not encrypted, hashed, salted or otherwise protected.

I suppose the Percona module does the same, although it is not being mentioned in the docs at all (or at least I have not been able to find it in there). They also openly suggest to run the database server as root, as that is the only way for an in-process PAM auth module to be able to access /etc/shadow.

*headdesk*

Does any of you know what SASL is and why it has been invented?

I know it's a pain, but it is there for a reason. Many reasons. saslauthd for example will read your authentication secrets instead of your worker process, because you are unable to write and maintain a secure codebase the size of a database server. And by speaking SASL on the wire and then handing off an authenticated connection to your actual worker code you gain access to a number of integrated mechanisms for communicating passwords in a compatible and secure manner, none of which include clear text passwords on the wire.

Can we please bury these plugins, deeply in the Mariana trench, in a CASTOR, put a warning beacon over the site and then start over, doing it right this time?

Thanks. I knew you would see the light eventually.

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

Kristian Köhntopp on :

To be fair, pam-1.1.3 does have unix_chkpwd, a SUID root program, that allows you to access /etc/shadow through pam_unix.so without actually making your mysqld root.

Previous PAM versions apparently did not have that (still checking this).

Raghavendra on :

I think you are comparing apples and oranges here (for the lack of a better term).

Having PAM functionality has nothing to do with SASL or other auth mechanisms (though SASL etc would be good to have).

From what I understand, pam will be primarily used in intra-server setting, so I see something like SASL for that as a overhead. If you are worried about snooping in such a setting, you have other bigger issues to be worried about regarding that server. Regarding authenticating users with shadow, a setuid helper is not something one would consider completely safe again.

This is where PAM benefits the most, it gives you the flexibility to plug/stack whatever auth mechanisms (there are tons) you like/however you want. It may be possible to add sasl to pam stack as well (which in turn checks with others), if such a module exists/written.

PAM is *not* just for authentication, it can do much more (session, account etc)

Regarding running root, linux provides a capabilities model as well which can be explored.

Andrey on :

With PHP 5.4, when using mysqlnd the PAM authentication is built-in, no need for an external module.

Joro on :

SASL is great and all. And we can also do what SASL does ourselves (as it proven by the mysql password wire exchange format).
Unfortunately the PAM interface is pretty straight forward : it needs a password. In clear text. Or at least that's what it says.

Wlad on :

If PAM need clear text password, it is very likely just unusable for client-server communicstion. It very limited cases it might be usable - client and server on the same box, or you're inside a VPN, or use SSL (however, SSL is already an authentication protocol, thus why bother about PAM if SSL is already in use)

Stewart Smith on :

There is a reason we labelled it an early access release.

The clear password over-the-wire is a requirement for using the standard client plugin that ships with every MySQL version... and initially it's a choice between compatibility and security.

SASL is quite possibly a solution.

That being said, pam_unix was a simple example to show people and is available everywhere. You'd be surprised how scarce some of the other PAM modules are.

Kristian Köhntopp on :

I can see the intention. I do not approve at all, though. These are now three plugins from three different companies, and they are all demonstrating several wrong and dangerous practices.

Yet there are exactly zero implementations available that are doing it even remotely right. This is completely and utterly wrong, because it teaches thousands of people the wrong thing, and leads them to think that this is somehow okay and one is getting away with it.

One of the technical authors that I have greatest respect for is the late W. Richard Stevens. He wrote a number of books on all topics UNIX and Internet, and not only was his writing brilliantly clear and to the point, also his programming examples were enlightening.

This is, because he refused to write or release incomplete or wrong examples. He made it a point that all of his demonstration code is production quality, taking all typical security and safety measures into account.

At the same time he managed to provide examples that were short enough to be printed in a book without turning said book into a wasteland of code listings (TCP/IP Illustrated, Part 2 excepted, but that wasn't his code, and also the point of the book was to print the complete source and comment on it).

I think that all three companies, Oracle, Monty Program and Percona, would do well to stop here, read a bit of Stevens and take his lessons to the heart.

Because what I see right now, frankly, sucks. And I know the people working in these companies, and I know for sure that they can do better. Because I have been seeing them doing it.

Daniël van Eeden on :

It's indeed important to understand the fact that the communication is clear text. Using one-time-passwords (e.g. OPIE) might solve this for now. And other solutions like SASL and/or kerberos might solve this completely some day.

An of course this is only the beginning, there is much more possible with the authenication plugins.

Baron Schwartz on :

This is clearly a weak solution in some ways. But I think it's important to understand that this was basically a sponsored feature that a customer specified and paid for, and then it was released as opensource. For some large users who have tight control over their infrastructure, the most important thing for them is integration with existing systems and ease of management. I know many places where people express the frustration "why can't MySQL use external auth? I have EVERYTHING in my whole infrastructure managed centrally, except for the $##*@ MySQL user accounts." This is a serious pain for those users, and very costly -- in real dollars.

In summary: this is clearly not for everyone, but it's for some people -- so why paternalistically deny them something of benefit?

Kristian Köhntopp on :

See #4.1 above. Three companies sending the completely wrong message publicly, zero correct and secure implementations.

That, too, is very frustrating.

If you want to integrate MySQL into an enterprise infrastructure, please do it right. That is, not running the server as root, and also not sending cleartext passwords over the wire, ever.

This is the kind of stuff that maybe some people are doing in the secrecy of their server rooms if it is their kink, and it is between them and their sysadmins. But it is nothing that anyone should release publicly, especially not any vendor - they are setting examples. Currently, the completely wrong examples.

Stewart Smith on :

The stock MySQL dialog plugin is even worse than sending things in clear text over the wire, it echoed it all to the screen too.

i.e. interactive 'mysql' would print your password on the screen *and* send it in plain text over the network.

What ships with MariaDB and what's in the next Percona PAM plugin release will have a fixed dialog plugin where at least this bit is closed.

As you can imagine, having a story for not sending passwords in the clear over the wire is a good thing, as is not running mysqld as root to get pam_unix. i.e. things we'd quite like to solve before naming anything "1.0".

We also need to (of course) solve the testing problem - which for PAM things is a tad interesting :)

Brian Aker on :

We implemented the PAM module a couple of years ago. The basic problem is that the MySQL protocol is pretty lame, and just not designed with any sort of concept of security (and FWIW, the rest of the open source databases have similar issues).

None on :

What is wrong with the author of this post ?
Why cannot he use http://dev.mysql.com/doc/refman/5.5/en/secure-basics.html
to protect password ?

Kristian Köhntopp on :

Are you aware of the performance consequences of SSL usage in database connections?

hartmut on :

Now the Connector/J implementation of mysql_clear_password, unlike the C client library implementation, wants to enforce SSL.

http://bugs.mysql.com/bug.php?id=65992

That may look like a good idea at first, but if encryption is already taken care of on a lower level (IPsec, VPN, direct tunnel, ...) you end up with double encryption overhead.

Also having two different connector products from the same vendor handling this differently sucks big time (and don't get me started about Connector/NET that so far only seems to support the proprietary windows auth thing but not the general client side auth plugin mechanism)

PS: mysql_clear_password does not need to be loaded into the client, it is statically compiled in and so it is the only client side auth plugin which can be guaranteed to be present ...

Mark Matthews on :

And all it takes is for one route to change, and boom, your password is back in the clear, without you knowing.

That is why we decided to play it safe in the JDBC driver, and only allow cleartext if *we* controlled the encryption. That level of paranoia, is what the majority of Java users expect.

Kristofer Pettersson on :

The clear text plugin is obviously intended to be used with either the socket transport or using SSL. Maybe you should mention this?

Using SASL was considered but not deemed good enough because of complexity and performance among other things. I think you highlight the issues well with "it is a pain".

cheers,

Kristofer
Evil corporate security lead (ecsl)

Kristian Köhntopp on :

Check out http://opensource.apple.com/source/OpenLDAP/OpenLDAP-143.4/OpenLDAP/contrib/slapd-modules/nssov/nss-ldapd/compat/getpeercred.c or similar code for proper safe Auth over sockets.

And I will find you the slides from Rasmus Lerdorf for the overhead of SSL. SASL may be a pain, but is cheaper and actually less painful than SSL.

Add Comment

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA

BBCode format allowed