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.
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 :
Previous PAM versions apparently did not have that (still checking this).
Raghavendra on :
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 :
Joro on :
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 :
Stewart Smith on :
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 :
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 :
An of course this is only the beginning, there is much more possible with the authenication plugins.
Baron Schwartz on :
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 :
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 :
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 :
None on :
Why cannot he use http://dev.mysql.com/doc/refman/5.5/en/secure-basics.html
to protect password ?
Kristian Köhntopp on :
hartmut on :
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 :
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 :
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 :
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.