Tuesday, December 6. 2011
pam modules for MySQL: What is wrong with these people?
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
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).
Previous PAM versions apparently did not have that (still checking this).
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.
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.
With PHP 5.4, when using mysqlnd the PAM authentication is built-in, no need for an external module.
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.
Unfortunately the PAM interface is pretty straight forward : it needs a password. In clear text. Or at least that's what it says.
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)
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.
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.
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.
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.
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.
An of course this is only the beginning, there is much more possible with the authenication plugins.
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?
In summary: this is clearly not for everyone, but it's for some people -- so why paternalistically deny them something of benefit?
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.
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.
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 :)
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 :)
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).
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 ?
Why cannot he use http://dev.mysql.com/doc/refman/5.5/en/secure-basics.html
to protect password ?
Are you aware of the performance consequences of SSL usage in database connections?
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 ...
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 ...
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.
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.
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)
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)
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.
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.
Quicksearch
Comments
about Enemy Action
Wed, 31.10.2012 13:46
My friendly Offtopic Channel
in IRC has horror stories
about this, it is Halloween,
after all.
"Well, I do
have [...]
Mon, 15.10.2012 09:41
What if we use SSDs. Can we
then assume memory limits
are not as significant
because SSDs can handle
random access [...]
Fri, 05.10.2012 07:46
In fact, I am pretty certain
that this also breaks
mysql_upgrade or has the
potential to do so.
Fri, 05.10.2012 06:44
It is quite a bit worse than
that: Right now, the default
RPM as distributed by Oracle
will fail to install if it
[...]
Thu, 04.10.2012 18:52
> MyISAM in mysql.* has to go
before GTID can be
sucessfully deployed.
I
think you meant to say
before it can b [...]
Thu, 04.10.2012 18:36
Sorry, it wasn't clear given
that none of this is
actually mentioned.
Thu, 04.10.2012 13:47
You can turn it on with FLUSH
PRIVILEGES once the tables
exist.
Categories
Community (14)- DBA
- DBA Tools (3)
- I18N (3)
- Monitoring and Merlin (5)
- Operating System (6)
- Replication (5)
- Scaleout and Tuning (10)
- Security (4)
- SQL (11)
- Strangeness (8)
- Development
- Bugs (3)
- Building (1)
- Devtools (1)
- Features (2)
- Releases (8)
- Engines (2)
- InnoDB (5)
- Memory
- MyISAM and Maria
- Jobs (9)
- Languages
- LUA
- PHP (7)
- Ruby (1)
- Miscellaneous (7)
- MySQL Proxy
Authors
Syndicate This Blog
Blog Administration
Disclaimer
All examples, code-snippets, advice, trivia, etc. are supplied in the hope that they are useful, but no warranty of any kind is given. Use of trademarks is not intended as a challenge to them.
Impressum
Copyright 2005-2012 bei den jeweiligen Autorinnen der Beiträge. Die Infrastruktur von MySQL-dump wird betrieben von:
Azundris, Immanuelkirchstraße 18, 10405 Berlin, Germany