By default, when using non-clear authentication (cram-md5, digest-md5, etc), sasl accesses /dev/random for random data to using in building hashes and keys. Unfortunately, because A) /dev/random blocks when the kernel has not gathered enough entropy, B) the kernel gathers entropy largely from keypresses and other random user-driven events, and C) many (most?) servers have no user at the console, we end up with a situation where /dev/random is constantly starved for entropy. This make almost every non-clear authentication block, sometimes for many minutes, before the user can continue, which is horrible. The delay is often long enough to time out the client connection and kill the connection attempt entirely which is horrible^2. Even worse, this wastes the precious entropy that had already been gathered for that attempt, further exacerbating the problem, which is horrible^3. The final result is that secure authentication is unusable. Fortunately, the solution is simple. Direct sasl to use /dev/urandom instead of /dev/random. The cyrus-sasl devs discuss this problem in reference to APOP (because for APOP it blocks even clear authentication because a hash is generated for the headerline of ALL POP connections) at http://acs-wiki.andrew.cmu.edu/twiki/bin/view/Cyrus/POP3DevRandomIssue. However, the problem actually extends far beyond APOP, affecting all non-clear authentication. They do specifically say that sasl does not have a need for high-quality randomness as /dev/random provides, and suggest the use of /dev/urandom to solve this problem. To address this and similar issues, I propose that a new global USE flag, "urandom", be added which causes any application build that supports it to use /dev/urandom instead of /dev/random. Changes for the cyrus-sasl ebuild in particular are trivial: Add "urandom" to IUSE and this line to src_compile: use urandom && myconf="${myconf} --with-devrandom=/dev/urandom" Thanks much. Note: I'm sorry if I made a bad call by marking this as MAJOR, but the major feature of SASL is secure authentication, and in my opinion, this major feature is currently BROKEN. Reproducible: Always Steps to Reproduce: 1. emerge cyrus-sasl 2. Do any significant amount of non-clear sasl authentication. Actual Results: Almost all non-clear authentications block after AUTH, often for many minutes, often timing out the connection. Expected Results: All authentications should respond instantaneously, and not block.
I notice new (still masked) ebuilds are using use_with. To match that, I changed my ebuild so urandom is added to IUSE and this is added to src_compile: myconf="${myconf} `use_with urandom devrandom /dev/urandom`" Still works fine for me.
I'd like to confirm that the patch works as advertise. :)
this is what I've gathered: # grep '\(\/dev\/random\|\/dev\/urandom\)' /usr/portage/* -R | grep ebuild dev-java/xerces/xerces-2.6.2.ebuild: addpredict /dev/random dev-java/xerces/xerces-2.6.1.ebuild: addpredict /dev/random dev-java/xerces/xerces-2.6.2-r1.ebuild: addpredict /dev/random dev-java/xerces/xerces-2.6.0.ebuild: addpredict /dev/random media-sound/audio-entropyd/audio-entropyd-0.0.6.ebuild:DESCRIPTION="Audio-entropyd generates entropy-data for the /dev/random device." net-dns/bind/bind-9.2.3.ebuild: mknod ${CHROOT}/dev/random c 1 8 net-dns/bind/bind-9.2.2-r3.ebuild: mknod ${CHROOT}/dev/random c 1 8 net-dns/bind/bind-9.2.2.ebuild: mknod ${CHROOT}/dev/random c 1 8 net-dns/bind/bind-9.2.2-r2.ebuild: mknod ${CHROOT}/dev/random c 1 8 net-dns/bind/bind-9.2.2_rc1-r2.ebuild: mknod ${CHROOT}/dev/random c 1 8 net-dns/bind/bind-9.2.2-r1.ebuild: mknod ${CHROOT}/dev/random c 1 8 net-dns/pdnsd/pdnsd-1.1.11.ebuild: [ -c /dev/urandom ] && myconf="${myconf} --with-random-device=/dev/urandom" net-dns/pdnsd/pdnsd-1.1.9.ebuild: [ -c /dev/urandom ] && myconf="${myconf} --with-random-device=/dev/urandom" net-dns/pdnsd/pdnsd-1.1.10.ebuild: [ -c /dev/urandom ] && myconf="${myconf} --with-random-device=/dev/urandom" net-www/apache/apache-2.0.49-r1.ebuild: --with-devrandom=/dev/urandom \ net-www/apache/apache-2.0.49-r3.ebuild: --with-devrandom=/dev/urandom \ sys-libs/nss-mysql/nss-mysql-0.43-r1.ebuild: cmd="${ROOT}/bin/dd if=/dev/random bs=32k count=1 2>/dev/null | md5sum | awk '{print \$1}'" It looks like only net-dns/pdnsd and net-www/apache are configured with "devrandom" and they both configured to use /dev/urandom. As the reporter stated /dev/random is almost not usable, so I think we could just configure cyrus-sasl to use /dev/urandom without the need of USE flag. diff snipset: --with-dbpath=/etc/sasl2/sasldb2 \ + --with-devrandom=/dev/urandom \ ${myconf} || die "econf failed"
That would certainly be fine with *me*. I was just concerned that a) it might turn off the paranoids :D and b) it might go against the Gentoo philosophy of choice. I suppose if other packages are doing it, though... ;)
I disagree with some of the arguments here, however, I do realize there is a need for more flexibility with cyrus-sasl. First of all, if a server does not have enough entropy, that is the administrator's problem. The Gentoo hardened team has provided a number of ways to gather entropy in a server environment: netdev-random kernel patches (network devices can contribute to entropy), audio-entropyd (gather entropy from sound card mic input), and hardware random device turned on by default in the kernel config. Hardened has even addressed SSP entropy-draining issues by making an "erandom" USE flag for glibc. It's an administrator's job to make sure a server has enough entropy. Using the /dev/urandom device only hides the problem. I think that if Gentoo makes decisions based on a USE variable as to which random device to use, this will raise many security concerns. Switching between blocking and non-blocking devices can be problematic. It's not just an issue of strength of encryption. The decision to use a particular random device should be code-dependent (an upstream decision), and in many cases different code in the same package may make use of different devices. If cyrus-sasl says that /dev/random is not necessary, why do they still default to using it? It seems to me that the cyrus-sasl developers should resolve this issue.
My first instinct is that the devs really should make this a runtime option. Unfortunately, they have not done so, and I've seen no indication that they intend to (they feel it's too easily addressed at compile time, and I see their point). Gentoo, on the other hand, is supposed to be all about choice. A USE flag would address the problem without impacting the security of those not using it. Many other packages do similar things (see the USE flags "artswrappersuid" and even netcat's "GAPING_SECURITY_HOLE"). A great many packages go so far as to have full-blown source patches applied based on USE flags, certainly far more impacting than simply changing a random-device. You say that it's an admin's responsibility to make sure his/her server has entropy. I disagree: I believe it's every admin's responsibility and right to *decide* how much entropy his/her server needs. The possibility of exotic kernels and kernel patches was also discussed. It is unfair to suggest that such kernels are the only way to run an application as UNexotic as "mail server." It's even less reasonable once you consider that you want me to go to the trouble of running that kernel, deal with the resulting incompatibilities, install a sound card that a mail server doesn't need, and have my kernel constantly poll these entropy sources (of questionable quality in the case of the network interface), which all increases the load on my server, all for the purpose of gathering entropy *I don't need*. ---OR--- Make a two-line change to the ebuild. It hurts noone, helps many, and gives us choices.
Ok, I still hold the same optinion here, so I'll just address your comments, Mike. The issue with the cyrus-sasl maintainers is simple. Does it matter if pulling from a random device blocks? If it doesn't, use /dev/random. If it does, use /dev/urandom. It sounds like they probably have done this, and are refusing to change the behavior for the same reason I am! /dev/random is constantly replenishing. If you do not have enough entropy to return random data at a paricular time, the worst that could happen is that an application has a slight delay until there is enough data. If there is so much activity on a server that the entropy available stays at 0, then the administrator has failed. There are dozens of secure applications that absolutely require entropy-chcked random data. cyrus-sasl is just one of many. Are you going to ask us to modify every single app so that it uses /dev/urandom? Yhis isn't really just about one package. An administrator certainly has the right to simply "give up" and decide that they cannot address the entropy problem. If that is the case, using /dev/urandom is not even the right answer! /dev/urandom still depletes system entropy. The correct solution is to use a psuedo-random device such as /dev/erandom. This may seem new and ridiculous, but I believe that is because of the great deal of misunderstanding surrounding random devices. It is only now, unfortunately, being addressed, and hopefully the frandom/erandom patch will be added to the default kernel tree sooner rather than later. All someone has to do is read /usr/src/linux/drivers/char/random.c to understand this issue, but no one ever does. Choosing a kernel is your choice. Gentoo makes it very easy. Show me proof of concept code that you can influence kernel random data from an external network interface with the netdev-random patch. Netdev-random has been available for abour 3 years now. If you are concerned about entropy and true security on your server, then your server probably needs a sound card. It sounds ridiculous, but it's true. Either that or make sure the motherboard has a hardware random device. Polling the devices mentioned for data to contribute to entropy barely touches your server load. Have you tried it? I run these things on a dozen servers and have no load problems. Adding a local use flag may seem like a simple thing, but from a larger perspective, it's too easy to use this type of solution as a band-aid rather than addressing the real issue. I would be willing to make a local use flag, called "BADIDEA" or something remeniscent of the netcat ebuild. I would much rather support the "erandom" use flag and have cyrus-sasl use /dev/erandom, which is the correct solution for admins that do not care about encryption security. What does everyone else think?
Actually, /dev/erandom would be a wonderful solution. If that will make it into the main sources soon, I'd be all for that. To answer your question, no, I'm not for adding a urandom option to all packages that use entropy (you've convinced me that a global use flag is, indeed, a bad idea). Only ones for which the quality of that entropy is not important, (such as this one, as stated by upstream). If cyrus-sasl is the only such case, then so be it. Please keep in mind that /dev/urandom is not /dev/zero. :D It still provides decent-quality entropy, it just may be of *lower* quality than /dev/random is guaranteed to be.
Mike, for now please take a look at rng-tools. # emerge -s rng-tools Searching... [ Results for search key : rng-tools ] [ Applications found : 1 ] * sys-apps/rng-tools Latest version available: 1.1 Latest version installed: [ Not Installed ] Size of downloaded files: 78 kB Homepage: http://gkernel.sourceforge.net/ Description: Daemon to use hardware random number generators. License: GPL-2
I did consider rng-tools, but unfortunately, my mobo has no hardware RNG. :(
I have cyrus-imap running on a server hosted under user mode linux, and it is perpetually short on entropy in /dev/random. When I used the default cyrus-sasl saslauthd for authentication, it took about 60 seconds for me to see my mail. I edited my cyrus-sasl-2.1.19-r1.ebuild and added a urandom flag, restarted my services, and now it takes about one second. I need a urandom USE flag for cyrus-sasl.
Created attachment 41390 [details, diff] Patch to cyrus-sasl-2.1.19-r1.ebuild adding urandom USE flag This patch adds urandom support for cyrus-sasl.
Ken, Please read comment #7.
I'd like to point out that the documentation referenced by Cory (/usr/src/linux/drivers/char/random.c), actually states that /dev/urandom is cryptographically strong, while the author of frandom/erandom (http://frandom.sourceforge.net/) specifically recommends against using frandom/erandom for cryptographic purposes (though he also says there doesn't seem to be a hard reason it shouldn't be ok - go figure).
For me, without or with the patch here under, cyrus-sasls-2.19-r1 fails with this access violation summary : open_wr: /dev/random open_wr: /dev/random open_wr: /dev/random This is the command : [ebuild N ] dev-libs/cyrus-sasl-2.1.19-r1 -authdaemond -berkdb -debug +gdbm +java -kerberos +ldap +mysql +pam -postgres +ssl -static +urandom 0 kB I've even tried to change the access right of /dev/random, but same result.
mindtech@, your problem have nothing to do with this bug, see bug #57693 if it solve your problem.
@ comment #10 If your system doesn't have hardware RNG, rng will fall back to /dev/urandom # /etc/init.d/rngd start * Starting hardware RNG daemon ... * No hardware RNG found, using /dev/urandom as feedback input [ ok ] closing as WONTFIX.
Well, at least that makes the ebuild work. I certainly don't consider it ideal, since this means compromising the randomness of all applications using /dev/random, including those that, unlike cyrus-sasl, *do* need good randomness (like persistent key pair creation, for example). But, if you refuse, you refuse. What more can I do? Se la' vie. I'll continue to put in the one-line fix recommended by upstream myself when new versions come out, ad infinitum.
*sigh* On second thought, one more try at pointing you guys at what upstream says. I just noticed that they now state it even more clearly than before, at http://asg.web.cmu.edu/cyrus/download/sasl/sysadmin.html : "The included mechanisms, besides OTP and SRP, use random numbers only to generate nonces, so using /dev/urandom is safe if you aren't using OTP or SRP." To answer Cory's conjecture that they don't change to /dev/urandom because they tested it and it didn't work: the above states flat-out that your assumption is incorrect. The only reason /dev/random is the default is that there are SOME configurations (namely, those using OTP and/or SRP) for which it *is* crucial. At present, these are not commonly used (yet, anyway), so /dev/urandom is perfectly fine. USE flags are for being able to set compile options in the most appropriate way for the user's environment, and this is a perfect example of something that varies by environment. I don't understand why you refuse to use the "USE" functionality for exactly the purpose for which it was designed. Furthermore, given your own arguments that high-quality randomness is so important for some applications (and it is), I'm simply aghast that your proposed solution is to use rngd on hardware without an RNG to subvert /dev/random's entropy entirely. I'm reopening the bug just to make sure someone looks at this again since I've provided a new citation where upstream makes it clear. Continue being wrong and WONTFIX it again if you must.
I think we should add a USE flag to use /dev/urandom instead a /dev/random. I think so because: 1) Is gentoo philosophy 2) Doesn't do any harm to those people using /dev/random 3) It's also upstream's opinion I can take care of it if no one oposses. Cheers, Ferdy
Added urandom useflag in cyrus-2.1.20-r2. Cheers, Ferdy
FWIW, I've been using /dev/random in the same way the bug reporter describes for > 1 year now and I've never seen the problem discussed by the bug reporter. Nice to have the option of /dev/urandom I guess, but I just never had the need for it.
As I said, it only tends to affect servers with significant numbers of connections using encrypted SASL authentication, thereby significantly draining entropy (note that this leaves out most users, who use default mail client settings and such that use insecure connections - my server, for example, *only* allows encrypted IMAP authentication, as well as encrypted authentication for SMTP relaying). Further, it is more pronounced on headless systems where there is zero user interaction at the console (like mine) which is the usual source of entropy. In any case, whether you've seen it or not is irrelevant. It's a known fact. I don't imagine you'd expect Gentoo to remove all USE flags that you yourself don't happen to use, correct?
*** Bug 110119 has been marked as a duplicate of this bug. ***
