Re: Copy mbox to Cyrus, user account
Forrest Aldrich wrote: I have a situation where a user needs her old email copied from an mbox into her new Cyrus account. Easy enough; however, she's a remote user and her auth is via SASL. So, it would potentially require me to either 1) get her password, or 2) reset the password on Cyrus so I could use "imapcopy" (or some other tool). Assuming the mbox is a normal mailbox file you could use an IMAP client that knows about proxy authorization: authenticate as an IMAP admin (cyrus) and authorize as the user in question, so you could perform all transfer operations under the user privileges. I know at some point on the list somebody suggested using mbxcopy from imapd-tools (UW tools, requires c-client from their site also). mboxcopy knows about proxy authorization and trasfers from any format c-client understands (mbox, pop3, imap) to other format. I have been using it (a modified version which included the cyrus password) to backup the imap mailboxes to regular flat mbox format. I don't recall if somebody on the list posted or just said that he patched mboxcopy to get the admin password via an environment variable rather than hardcodeit into the program (like I did). There must be an easier way to do this that I've not seen... ? I must admin it sounds simpler than it actually is to implement, you could just change the password temporarily and restore it back with the original sasldb2. hth, mitu --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Copy mbox to Cyrus, user account
Hi, Forrest Aldrich schrieb: I have a situation where a user needs her old email copied from an mbox into her new Cyrus account. Easy enough; however, she's a remote user and her auth is via SASL. So, it would potentially require me to either 1) get her password, or 2) reset the password on Cyrus so I could use "imapcopy" (or some other tool). There must be an easier way to do this that I've not seen... ? depends on your config. We use PAM with LDAP (checked first) and winbind. I usally use this to define mailaccounts w/o creating a windows account, but if you create a user with same credentials like windows (user/pass, anything else is unimportant) in LDAP, he is authed by that first. After copying the box, delete him from LDAP. CU Michael --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
IOERROR's problem
Hi people, some days ago we changed our mail server. We were running a cyrus-imapd 2.1 on a Red Hat 7.2 box and now we installed a cyrus-imapd 2.2.10 on a Debian Sarge. To do the migration I copyed all the users mailboxes and mail files (spool directory) and the mail "data" (lib directory) to the new box and, following the instructions from Cyrus page I converted the old seen files to skiplist. I did a reconstruct -rf user.* and all seemed to be running ok, also seen states. The clients who are using this mail server are all MS Outlook XP. I know it doesn't have a good IMAP support, but our users wanted it. With some rules at clients we managed to store sent-mail on the IMAP server automatically, but after some hours of use, that rules failed. Trying to connect to the sent mailbox results on a System I/O Error on the client. The cyrus log, says more or less the same: /var/log/syslogd: imap[31053]: IOERROR: opening /data/mail/spool/cyrus/mail/user/ecolmenero/Elementos eliminados/cyrus.cache: No such file or directory I looked for that file (cyrus.cache) and it exists. It doesn't happen to all users at the same time, I mean one user can have the error while other user is working ok. But when accessing a mailbox fails, almost all the user's mailboxes fail too. I know hot to fix the error. If I reconstruct that user's mailboxes all works ok again, but the IOERROR appears again after some hours of works. I don't know how to reproduce it... Anyone knows how to fix it? I installed the last cyrus-imapd version (2.2.12) but it didn't fix it. The error appears many times a day... Is it a cyrus-problem? Outlook?? Maybe useful data: - Users have between 2000 to 6000 mails on the sent folder... - /etc/imapd.conf configdirectory: /data/mail/lib/cyrus defaultpartition: default partition-default: /data/mail/spool/cyrus/mail partition-news: /data/mail/spool/cyrus/news newsspool: /data/mail/spool/cyrus/news altnamespace: no unixhierarchysep: no munge8bit: no admins: cyrus allowanonymouslogin: no autocreatequota: 50 umask: 077 sieveusehomedir: false sievedir: /data/mail/lib/cyrus/sieve hashimapspool: false sasl_mech_list: PLAIN allowapop: no sasl_pwcheck_method: saslauthd sasl_auto_transition: no lmtpsocket: /var/run/cyrus/socket/lmtp idlesocket: /var/run/cyrus/socket/idle notifysocket: /var/run/cyrus/socket/notify I hope anyone can help me. I don't know where to look and didn't find anything in google... Sorry for my poor english. Thanks to all in advance. Javi Martín Dpto. Sistemas Unix Oasys Soft --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus POP3 Issue
Henrique de Moraes Holschuh wrote: On Thu, 03 Mar 2005, L. Mark Stone wrote: The POP server component is giving us a problem. It often fails to respond to connection requests in a timely manner, if at all. IMAP Disable APOP, or get SASL to use /dev/urandom like it should be doing in any sane distribution (SASL is not generating long-term keys which would be a good reason to use /dev/random). You do want to use /dev/random for your session keys. _They_ are likely going to attack your session keys, not your master key. The whole point is to guess as many bits as possible of the kernel PRNG state. /dev/random blocks when the kernel thinks the PRNG state could have already been guessed, in pure theory. So the attacker would be able guess its _next_ output. By reading from /dev/urandom, you're accepting the risk (the output is protected by a crypto-strong hash function, such as SHA1, anyway - but you have to trust it). Once the attacker knows the output of your /dev/urandom, he knows all the session keys your host will generate. Note that since you've generated the master keys offline, in an unknown time on an unknown computer, the attacker knows _nothing_ about the PRNG state of the machine you used. You could have used /dev/urandom for them w/o any risk, unless the attacker was able to observe you in that moment[*]! The only thing that could help him is a bug in the PRNG and the hash function, so that some bit strings are impossible (or unlikely) to be generated. That would allow him to discard them in a brute force search. It happened in the past, some software used to generate 128 bit keys was buggy and the actual number of possible combinations was much much smaller (say 2^20). But the same PRNG and the same hash function are used by /dev/random as well, so it isn't much safer in this respect. If your kernel runs out of random bits, you should find a reliable source of randomness and feed it into the kernel. .TM. [*] assuming the keys you generated are not longer than the kernel internal pool, in bits. If the PRNG state is 4096 bits, and you are generating a 8192-bit key out of /dev/urandom, the attacker needs only to try 2^4096 possible combinations, not 2^8192. Usually the kernel pool is large enough (and can be enlarged at run time in modern Linux kernels). -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus POP3 Issue
On Fri, 04 Mar 2005, Marco Colombo wrote: > You do want to use /dev/random for your session keys. _They_ are > likely going to attack your session keys, not your master key. The whole > point is to guess as many bits as possible of the kernel PRNG state. Which, in a Cyrus server, won't be helpful since there is a lot of disk activity and the PRNG state changes quite often, provided you don't keep it drained (and thus without activity because nobody can talk to the server!). Using random instead of urandom goes a long way into helping to keep the pool drained (the kernels usually protect a small amount of entropy won't let urandom drain it completely). > /dev/random blocks when the kernel thinks the PRNG state could have > already been guessed, in pure theory. So the attacker would be able guess The hard facts are that most kernel entropy accounting is not anywhere close to exact enough, so we cannot rely on it on anything close to a border condition (such as the entropy pool being empty, which is the only time urandom differs too much from random). You *are* already depending on the security of the PRNG for small ammounts of time (when the entropy in the pool is "close" to zero). Given that fact, IMHO you are much better using urandom anyway, because the system will still work enough close to an empty entropy pool to regen that pool a bit. > anyway - but you have to trust it). Once the attacker knows the output of > your /dev/urandom, he knows all the session keys your host will generate. If, and only if, you have no new entropy going in. If you have a few bits of entropy going in, they have a reduced search space (which IS already a very bad thing)... unless the kernel does a catastrophic reseed of the PRNG. Which on newer Linux kernels for example, it does as often as it possibly can. > It happened in the past, some software used to generate 128 bit keys was > buggy and the actual number of possible combinations was much much smaller > (say 2^20). But the same PRNG and the same hash function are used by > /dev/random as well, so it isn't much safer in this respect. It won't be any safer, you mean. Well, I am not afraid of the SHA search space, in Linux, BSDs and Solaris, that have somewhat good PRNGs. The state of the entropy pool changes unpredictably quite often enough. > If your kernel runs out of random bits, you should find a reliable source > of randomness and feed it into the kernel. I do. In fact, I have a 25kbit/s entropy feed into the kernel pool in such a way that I force a catastrophic reseed at least every second, and I am also working with the merkensleep.com guys to get rng-tools to a point where you can easily send entropy over the network from something like a VIA Nehemiah step 8 (a couple Mbit/s of entropy, sweet...) to a cluster. > to try 2^4096 possible combinations, not 2^8192. Usually the kernel pool > is large enough (and can be enlarged at run time in modern Linux kernels). At least so far. Someone was talking about removing "that useless feature", so keep an eye for it to make sure they don't. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus POP3 Issue [solved]
Fernando, Thank you very much, that fixed it! With best regards, Mark On Fri, March 4, 2005 3:36 am, Fernando Arconada Oróstegui said: > Yesterday i had the same problem in SLES9 and i found the solution > disabling APOP in /etc/imapd.conf with allowapop:0 > Its a problem with ramdom numbers and entrophy if you need APOP other > solution its to recompile saslauth to use /dev/random or to get a faster > machine. > > "L. Mark Stone" <[EMAIL PROTECTED]> 04/03/05 3:59 >>> > I'm running Cyrus 2.2.3 on SuSE Linux Enterprise Server 9, installed > from SuSE's rpm packages. > > The POP server component is giving us a problem. It often fails to > respond to connection requests in a timely manner, if at all. IMAP > shows no such problems; IMAP responds to telnet requests very fast > indeed (like, within 60ms). The server hardware is not heavily loaded, > so we don't see this as a resource constraint issue. > > See for example: > inside:~ # telnet localhost 110 > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > > Sometimes the server responds with an "+OK..." immediately, sometimes > after 5-10 seconds, more often not at all. Nothing in the logs that we > can see. Googling and a review of the docs have yielded no hits, so we > are posting here. > > Basically, we are just trying to figure out where to start looking to > troubleshoot this. > > Any ideas/suggestions/pointers, etc. greatly appreciated, > Mark > > -- > _ > A Message From... L. Mark Stone > > Reliable Networks of Maine, LLC > > "We manage your network so you can manage your business." > > 477 Congress Street > Portland, ME 04101 > Tel: (207) 772-5678 > Web: http://www.rnome.com > > > --- > Cyrus Home Page: http://asg.web.cmu.edu/cyrus > Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu > List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html > > -- A Message From... L. Mark Stone Reliable Networks of Maine, LLC "We manage your network so you can manage your business." 477 Congress Street Portland, ME 04101 Tel: (207) 772-5678 Web: http://www.rnome.com --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
cvt_cyrusdb flat to skiplist fails
I have a strange behaviour here: annotations.db is in the skiplist format. Now cvt_cyrusdb seems to fail a simple back and forth conversion test to flat and back. How can that be? cvt_cyrusdb /tmp/annotations.db skiplist /tmp/x flat Converting from /tmp/annotations.db (skiplist) to /tmp/x (flat) Converting from /tmp/x (flat) to /tmp/y (skiplist) Warning: apparently empty database converted. Inspection with an editor shows that annotaions.db and x contain entries and y does not. Is this a bug? Background: I tried to test skiplist.py from http://oss.netfarm.it/python-cyrus.php for a recovery situation. It produces a great flat file, but cvt_cyrusdb does not grok it. Bernhard ps.: Please send me a copy of relevant replies. name : Cyrus IMAPD version: v2.2.8 2004/07/29 15:44:37 vendor : Project Cyrus support-url: http://asg.web.cmu.edu/cyrus os : Linux os-version : 2.6.6 environment: Built w/Cyrus SASL 2.1.19 Running w/Cyrus SASL 2.1.19 Built w/Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003) Running w/Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003) Built w/OpenSSL 0.9.7d 17 Mar 2004 Running w/OpenSSL 0.9.7d 17 Mar 2004 CMU Sieve 2.2 mmap = shared lock = fcntl nonblock = fcntl auth = unix idle = poll pgpzBU611YI9h.pgp Description: PGP signature
Re: lmtp over SSL - lmtps ?
Olaf Fraczyk wrote: On Wed, 2005-03-02 at 13:23 -0500, Ken Murchison wrote: Olaf Fraczyk wrote: Hi, Is there any way to make communication in a secure way using lmtp? I would like to have postfix and cyrus on separate machines. Do you really want to encrypt *all* of the traffic or just the authentication information? Your email is most likely getting to Postfix in plaintext anyways. lmtpd will support non-plaintext authentication methods (and should support TLS+PLAIN) Encrypting only the autenthication is the best (CPU utilization) and is enough for me. Do you know any Howto or FAQ where I can find something how to configure postfix and cyrus with non-plaintext authentication (the delivery between postfix and cyrus only of course). Cyrus does it out of the box, provided SASL is configured correctly. As far as Postfix, that is a question which I don't have an answer to. You should take that to the Postfix forum(s). -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Playing with replicated murder
Christoph Moench-Tegeder wrote: ## Ken Murchison ([EMAIL PROTECTED]): I am a little confused over the location of configdirectory, some of its contents (like the DB environment, the socket und the proc directorys) should be kept per node (I believe), while others (as quota files) should be shared between nodes. What about the replicated mailboxes.db? What am I missing? I'm assuming that your talking about the current code in 2.3 which uses MUPDATE to replicate mailboxes.db across multiple backends sharing the same spool. Yes, I forgot to mention that. Currently I'm using code from CVS as of 2005-02-14. mailboxes.db is local to each machine, as are deliver.db and tls_sessions.db The user's seen state and subscriptions, as well as quotaroots can be shared on the SAN. So basically /var/imap is local, but /var/imap/user, /var/imap/quota, /var/spool/imap are on the SAN. Are symlinks "the right way" to do that or did I miss something in imapd.conf.5? symlinks are fine. Note that the university that I wrote the code for has abandoned it because of problems with Sun's SAN filesystem. Hm. Polyserve claims their filesystem "exhibits the same behavior as an ext3 file system", but that's marketing... We will see. That's what tests are for :) In any case, I will report here. Is there anything special I should be aware of? Not that comes to mind at the moment. Let me know if you have questions. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus POP3 Issue
First of all, let me state that I don't really believe that attacking the internal state of the kernel PRNG is pratical at all. It is possible, in theory. Using /dev/urandom is pretty safe for many real-world uses. We're discussing theory here. Henrique de Moraes Holschuh wrote: On Fri, 04 Mar 2005, Marco Colombo wrote: You do want to use /dev/random for your session keys. _They_ are likely going to attack your session keys, not your master key. The whole point is to guess as many bits as possible of the kernel PRNG state. Which, in a Cyrus server, won't be helpful since there is a lot of disk activity and the PRNG state changes quite often, provided you don't keep it drained (and thus without activity because nobody can talk to the server!). Using random instead of urandom goes a long way into helping to keep the pool drained (the kernels usually protect a small amount of entropy won't let urandom drain it completely). Well, the problem is simple. Let's say your server generated 100 session keys in the last minute. If the system collected at least 100*key size random bits, you could have used /dev/random. If it not, and you used /dev/urandom, the attacker has fewer bits to guess. Let E be this number. Assuming that he knows the pool state _now_ (that is, he collects enough keys and is able to break SHA1 and reverse the PRNG algorithm to obtain its state), in order to get the pool state _one minute_ ago, he has to guess E bits only, which it is easier than guessing all 100 keys. Every _single_ bit you got out of /dev/urandom for your session keys when /dev/random would have blocked _halves_ the attacker's effort. /dev/random blocks when the kernel thinks the PRNG state could have already been guessed, in pure theory. So the attacker would be able guess The hard facts are that most kernel entropy accounting is not anywhere close to exact enough, so we cannot rely on it on anything close to a border condition (such as the entropy pool being empty, which is the only time urandom differs too much from random). You *are* already depending on the security of the PRNG for small ammounts of time (when the entropy in the pool is "close" to zero). Well, the accounting needs not to be accurate at all. _Underestimating_ the randomness in the pool is perfectly safe, and that's what the kernel does. You can add 1024 bits of "truly" random data to the pool, and account only 128 entropy bits. So, even if your "truly" random bits were not so random, you're ok, as long as _at least_ 128 were "truly" random. Since there's no way to make sure bits are "truly" random at all (all tests may fail, all devices may be somehow biased, and so on) you can only reach some level of confidence. Extracting N bits from a "good" source, injecting them into the pool, and accounting only M entropy bits, where M< The kernel is quite conservative in estimating randomness, that's why the pool empties so easily, expecially on headless servers. And no, you're not depending on the security of the PRNG+hash when you're using /dev/random, assuming they're not buggy. Given that fact, IMHO you are much better using urandom anyway, because the system will still work enough close to an empty entropy pool to regen that pool a bit. I'm not following you. Unless you're implying that the only source of randomness is the result of the activity the _needs_ the random bits. Such as a dedicated headleass cyrus server with no other entropy source but disk activity. If all new connections blocks on /dev/random, the disk activity will be lower. Well, first I think disk activity is much bigger for already connected clients. I know some clients out there make a new connections to the server everytime they check for new mail (once a minute?) but those are broken clients. I agree that with those, to block connections means to block activity. But most clients I know open _one_ connection to the server and keep it open. Sane clients generate most of their activity well after the connection has been established (and the session key exchanged). Blocking connections does not block their activity at all. Second, giving up security only to squeeze some more entropy bits from your disks isn't a winning strategy, IMHO. anyway - but you have to trust it). Once the attacker knows the output of your /dev/urandom, he knows all the session keys your host will generate. If, and only if, you have no new entropy going in. If you have a few bits of entropy going in, they have a reduced search space (which IS already a very bad thing)... unless the kernel does a catastrophic reseed of the PRNG. Which on newer Linux kernels for example, it does as often as it possibly can. I know that every single bit of entropy going in changes the state, but the attacker needs only to try the possible values. The reduced search space _is_ the problem. Whatever the kernel does, it doesn't do that "randomly enough", being only a program, thus a finite state machine. The attacker can guess _any_
server-wide sieve script
Hi cyrus users!
I have a simple question:
Is there a way to make a server-wide sieve script?
Example:
# Simple SPAM filter
require "fileinto";
if header :contains "X-Spam-Flag" "YES" { fileinto "INBOX.Spam";
Of what I found of the Internet, sieve is more user-oriented more than
server-wide oriented, if it's the case, do you have an alternative to
move mail to a specific folder? The solution suggested have to be
server-wide because I want to move spam to a special folder for all users.
My MTA is sendmail and I use milter-spamc with SA.
Thanks!
--
Gabriel Latour
UNIX system administrator
www.interplusonline.com
www.maximustelecom.com
514-620-9011 ext.102
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: lmtp over SSL - lmtps ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Olaf Fraczyk schrieb: > Encrypting only the autenthication is the best (CPU utilization) and is > enough for me. > Do you know any Howto or FAQ where I can find something how to configure > postfix and cyrus with non-plaintext authentication (the delivery > between postfix and cyrus only of course). I found this yesterday when I tried to configure my postfix to use lmtp authentication: http://www.irbs.net/internet/info-cyrus/0110/0258.html Maybe this helps. PS: You can override your global sasl options in cyrus with lmtp specific options, like lmtp_sasl_pwcheck_method and lmtp_sasl_mech_list. Regards, Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCKJVecKsx5K5ighwRAhvlAKCh19LdJDfSQz/WTOkfYaWFBNJ7+gCeL3S4 zsJ2EAO8Y6t2Y5nfbLL2mYQ= =FArh -END PGP SIGNATURE- --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus POP3 Issue
On Fri, 04 Mar 2005, Marco Colombo wrote: > First of all, let me state that I don't really believe that attacking the > internal state of the kernel PRNG is pratical at all. It is possible, > in theory. Using /dev/urandom is pretty safe for many real-world uses. Which *was* my whole point, that in real-world usage, we would be better off with SASL using /dev/urandom. OTOH, gnupg and openssl x509 stuff better use /dev/random... > We're discussing theory here. If we are going to go down that road, the explanation is very simple: we have to use /dev/random always. There is at least one far-fetched scenario where the attacker can keep the entropy pool empty (even the primary one that the kernel reserves for IP traffic and other high-priority entropy needs), and thus continuously break the PRNG and guess all session keys. That scenario assumes a lot of stuff like complete SHA break, complete PRNG break, capabilities to observe almost all output of the PRNG ordered on time, etc. So, why bother going the pure theory road, if it is useless to access just how safe (or unsafe) a real-world decision is? We have to at the very least, mix both approaches. > Henrique de Moraes Holschuh wrote: > >Which, in a Cyrus server, won't be helpful since there is a lot of disk > >activity and the PRNG state changes quite often, provided you don't keep it > >drained (and thus without activity because nobody can talk to the server!). > > > >Using random instead of urandom goes a long way into helping to keep the > >pool drained (the kernels usually protect a small amount of entropy > >won't let urandom drain it completely). > > Well, the problem is simple. Let's say your server generated 100 session > keys in the last minute. If the system collected at least 100*key size > random bits, you could have used /dev/random. If it not, and you used > /dev/urandom, the attacker has fewer bits to guess. Let E be this number. > Assuming that he knows the pool state _now_ (that is, he collects enough > keys and is able to break SHA1 and reverse the PRNG algorithm to obtain > its state), in order to get the pool state _one minute_ ago, he has to > guess E bits only, which it is easier than guessing all 100 keys. Every > _single_ bit you got out of /dev/urandom for your session keys when > /dev/random would have blocked _halves_ the attacker's effort. That is not taking into account that there are small amounts of entropy entering the pool (which WILL mess with blind backwards-in-time predicitions, since you cannot adjust for those. If it is non-blind, i.e. you have some blocks, you may be able to avoid this). That will not make the attack impossible, but it will increase the search space a bit (I have no idea how much). AND that also assumes no catastrophic reseeds, which completely reset the PRNG, and kills any possibility of blind predictions to the past. > >The hard facts are that most kernel entropy accounting is not anywhere > >close > >to exact enough, so we cannot rely on it on anything close to a border > >condition (such as the entropy pool being empty, which is the only time > >urandom differs too much from random). You *are* already depending on the > >security of the PRNG for small ammounts of time (when the entropy in the > >pool is "close" to zero). > > Well, the accounting needs not to be accurate at all. _Underestimating_ > the randomness in the pool is perfectly safe, and that's what the kernel Indeed. The problem is that the errors are not always to the safe side. The fact that all Linux kernels in the 2.4.x series will *over*estimate entropy fed *from userspace* by a factor of 4 doesn't exactly fill me with confidence that the other entropy accounting done by those kernels is ok. > Since there's no way to make sure bits are "truly" random at all (all > tests may fail, all devices may be somehow biased, and so on) you can > only reach some level of confidence. Extracting N bits from a "good" > source, injecting them into the pool, and accounting only M entropy bits, > where M< It's a tradeoff: your confidence vs. the cost of those N bits. Correct. > The kernel is quite conservative in estimating randomness, that's why > the pool empties so easily, expecially on headless servers. THAT is what I am NOT completely at ease with. I sure hope it is being quite conserative. > And no, you're not depending on the security of the PRNG+hash when you're > using /dev/random, assuming they're not buggy. Even if the entropy pool has zero bits of randomness but the kernel thinks it still has some? That was what I was talking about... > >Given that fact, IMHO you are much better using urandom anyway, because the > >system will still work enough close to an empty entropy pool to regen that > >pool a bit. > > I'm not following you. Unless you're implying that the only source of > randomness is the result of the activity the _needs_ the random bits. Not really. But most of the activity in a headless Cyrus serve
pointless select()s and IMAP connections in CLOSE_WAIT
Hi We're running Cyrus imapd version 2.1.17 on a FreeBSD server (4.11-RELEASE) with Cyrus SASL 2.1.19 and saslauthd. Everything is installed from the ports tree. In the middle of the day we get up to about 2000 concurrent connections to the IMAP port. Usually these connections are all ESTABLISHED according to netstat/lsof etc., but sometimes we suddenly get a huge spike in connections. If I look at netstat at that point, all the "extra" connections are in the CLOSE_WAIT state. # netstat -n | grep CLOSE_WAIT [...] tcp4 102 0 xxx.yyy.zzz.www.993 xxx.yyy.65.101.1480 CLOSE_WAIT tcp4 105 0 xxx.yyy.zzz.www.993 xxx.yyy.5.211.4289CLOSE_WAIT tcp4 0 0 xxx.yyy.zzz.www.993 xxx.yyy.35.232.1721 CLOSE_WAIT tcp4 84 0 xxx.yyy.zzz.www.993 xxx.yyy.28.3.3480 CLOSE_WAIT tcp4 98 0 xxx.yyy.zzz.www.993 xxx.yyy.66.14.50285 CLOSE_WAIT tcp4 0 0 xxx.yyy.zzz.www.993 xxx.yyy.28.34.1373CLOSE_WAIT tcp4 0 0 xxx.yyy.zzz.www.993 xxx.yyy.35.232.3552 CLOSE_WAIT tcp4 57 32147 xxx.yyy.zzz.www.993 xxx.yyy.5.182.1316CLOSE_WAIT The only fix for the problem appears to be to restart Cyrus. It I have a look at one of the processes with lsof, this is what it looks like: # lsof -i @xxx.yyy.65.101:1480 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME imapd 85462 cyrus0u IPv4 0xef4a0c00 0t0 TCP xxx.yyy.zzz.www:imaps->xxx.yyy.65.101:1480 (CLOSE_WAIT) imapd 85462 cyrus1u IPv4 0xef4a0c00 0t0 TCP xxx.yyy.zzz.www:imaps->xxx.yyy.65.101:1480 (CLOSE_WAIT) imapd 85462 cyrus2u IPv4 0xef4a0c00 0t0 TCP xxx.yyy.zzz.www:imaps->xxx.yyy.65.101:1480 (CLOSE_WAIT) If I look at the process with truss, it seems to be stuck in a loop calling select with no file descriptors! # truss -p 85462 (null)() = 0 (0x0) select(0x0,0x0,0x0,0x0,0xbfbfe808) = 0 (0x0) select(0x0,0x0,0x0,0x0,0xbfbfe808) = 0 (0x0) select(0x0,0x0,0x0,0x0,0xbfbfe808) = 0 (0x0) select(0x0,0x0,0x0,0x0,0xbfbfe808) = 0 (0x0) select(0x0,0x0,0x0,0x0,0xbfbfe808) = 0 (0x0) select(0x0,0x0,0x0,0x0,0xbfbfe808) = 0 (0x0) select(0x0,0x0,0x0,0x0,0xbfbfe808) = 0 (0x0) select(0x0,0x0,0x0,0x0,0xbfbfe808) = 0 (0x0) select(0x0,0x0,0x0,0x0,0xbfbfe808) = 0 (0x0) select(0x0,0x0,0x0,0x0,0xbfbfe808) = 0 (0x0) It seems as if some of the imapds suddenly forget which fds they are supposed to be reading from/writing to and just wait around for something to happen that never will. I've had a look around on the Cyrus mailing list archives, but haven't managed to find a solution to this problem. Is it a known problem? Thanks. -- Michael Wood <[EMAIL PROTECTED]> --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus and Usenet
On 28.02.2005 18:27, Ken Murchison wrote: kael wrote: On 27.02.2005 15:47, Ken Murchison wrote: Since you have enabled unixhierarchysep, you should create Usenet/comp/mail/imap This is the IMAP name of the mailbox. I ran : localhost.localdomain> cm Usenet/comp/mail/imap and tree sub-mailboxes have been created, I started nntpd and nothing is delivered into "imap". I still don't get it. :-[ Can an NNTP client access the server and see the comp.mail.imap group? You could also login in with nntptest and try: LIST GROUP comp.mail.imap You could also try using the POST command. I got the feed ! It works. Thank you very much. Actually, I got it earlier but didn't realised. I created the mailboxes, ran nntpd and it worked. How would the groups be named without unixhierarchysep ? Also, it seems that everybody can post from my server - how to disallow access for posting and more generally to manage posting or reading ? I've managed /etc/news with: -- default xferno -- according to http://howtos.linux.com/guides/nag2/x-087-2-nntp.access.shtml but not sure it works and it'd be enough. How to manage access (posting/reading) on port 119 ? Is /usr/lib/cyrus-imapd/nntpd -f enough ? http://linuxcommand.org/man_pages/nntpd8.html Also, it seems that ANNOTATEMORE is used to delete messages with cyr_expire, isn't it ? Need to read more about it. I thank you very much for your help. Cheers. -- kael --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
