Re: FAQ: What is saslauthd?
Jeremy Howard wrote: cc'd to cyrus-sasl Ken Murchison wrote: ...rather long thread where Ken and I confuse each other greatly snipped... One of the two of us is either confused or not being clear. Let's try to put this thread to rest :^) Sorry, no such luck yet :-( You can reply to this off-list if you think this is getting out of control--although so far we seem to be getting somewhere so maybe the discussion is good for the archives... Your statement above is NOT correct. pwcheck and saslauthd are completely independent of one another, and can (and will) use different protocols (check the SASL v2 source). If you look at configure.in, nothing prevents you from compiling support for both into a single SASL library. This means (in theory) that Cyrus could be using saslauthd and Sendmail could be using pwcheck. According to Christopher Audley in the message: http://asg.web.cmu.edu/archive/message.php?mailbox=archive.info-cyrusmsg=10 234: To the core sasl library, it looks just like pwcheck. Open a UNIX socket, pass in 'username\0password\0' and get back 'OK' or something else. saslauthd defaults to putting its socket in a different location from pwcheck, but it has a command line switch you can use to emulate pwcheck behavior. Because the protocol is essentially the same as pwcheck, you can lift saslauthd from a latter version of SASL and use it with your 1.5.24 SASL installation This is all true with SASL v1.5 ONLY!!! This will not be the case in SASL v2! I would consider the fact that saslauthd can be used as a pseudo-pwcheck daemon in v1.5 a temporary hack and should not be something that people should depend on. Sure, you can compile support for both, but all that means is you can have two different unix sockets for two different SASL-using apps. Of course Christopher's description above now needs to be updated to say pass in 'countusernamecountpasswordcountservicecountrealm' and get back '2OK' or something else. Now if we do change to that different wire protocol, I strongly suggest that it be changed for both the saslauthd _and_ the pwcheck sockets. Making that different would just be confusing, and would mean that pwcheck daemons would not be able to take advantage of the realm and service parameters. If we make the same change to pwcheck, then all existing pwcheck daemons will be broken. This is something that is clearly distasteful. This is why I made the statement below. I really don't see the need to have the two protocols the same. SASL v2 is moving towards saslauthd for plaintext password verification. pwcheck support is being maintained so that existing pwcheck daemons will continue to work out the box with SASL v2. They are simply different backends (along with sasldb) for the server side of SASL to verify plaintext passwords. I would consider the pwcheck support in SASL v2 for backwards compatibility only. Maybe we need a distinction between pwcheck-socket-support which is the ability to tell SASL to contact a Unix socket to authenticate, versus pwcheck-shadow-daemon which is the pwcheck daemon that comes with SASL 1.x for authenticating against the shadow file. The pwcheck-shadow-daemon is clearly redundent with saslauthd, because it is less flexible and less scalable. Agreed. The pwcheck-shadow-daemon is distributed as a working example of a pwcheck daemon. The shadow support in saslauthd will mostly likely be that which is used by default in SASL v2. The pwcheck-socket-support is (I don't think) for backwards compatibility only. It is the very wire protocol that saslauthd uses. This is only true in v1.5. It will NOT be the case in v2. If I were going to write a new authentication module/mechanism, I would do so using the saslauthd framework. Mainly because I only need to write a single protocol-agnostic function to interface with saslauthd. If I were going to write a new authentication module/mechanism, I would do so using the Perl-pwcheck framework. With this I only need to write a single protocol-agnostic function to interface with the Perl-pwcheck framework. I also get the benefits I mentioned in my last message (choice of forking models, no re-compilation, use of Perl rather than C). Note that this framework is not released yet, since I want to clarify these issues as they may effect the interface of Perl-pwcheck. Nothing is stopping you from continuing to develop against the pwcheck interface. If you don't like the forking model currently in saslauthd, submit a patch which makes it better, or continue to move in your current direction. Ken -- 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
Re: FAQ: What is saslauthd?
Jeremy Howard wrote: Ken Murchison wrote: Jeremy Howard wrote: Ken Murchison wrote: Now that I think about it, what's the difference? The pwcheck capability is not going away, so anything you have already written will still work. With saslauthd, the daemon itself speaks the protocol, NOT the backend mechanism. As long as the API for mechanisms doesn't change (which it will/has in the SASL v2 code), we should be able to change the protocol all day long without breaking the plug-in code. Sorry if I displaying ignorance here, but I was under the impression that saslauthd is simply a daemon that _does_ use the pwcheck API, except that the SASL configure script happens to set it up to use a different Unix socket to normal. So if saslauthd is using char-counted strings (which I now understand from Lyndon's message may reduce security problems) then the pwcheck interface must be changed to use these strings. Which means that daemons already written will have to be changed to use the new string format. Disclaimer: I have never used/implemented pwcheck, so please verify what I say, and corretc me if necessary. If by API, you mean the wire-protocol, then pwcheck and saslauthd _used_ to be the same, but I don't consider that an API. AFAIK, pwcheck doesn't have an API, where saslauthd does (even though the guts of both is very similar). Yes, by API I mean wire-protocol. And my understanding is that saslauthd is simply a daemon that uses the pwcheck wire-protocol under the surface. There will not be separate pwcheck and saslauthd wire-protocols--although the configure script for SASL will use a different port for the saslauthd daemon. Therefore the changing of the wire protocol will effect existing pwcheck daemons. One of the two of us is either confused or not being clear. Let's try to put this thread to rest :^) Your statement above is NOT correct. pwcheck and saslauthd are completely independent of one another, and can (and will) use different protocols (check the SASL v2 source). If you look at configure.in, nothing prevents you from compiling support for both into a single SASL library. This means (in theory) that Cyrus could be using saslauthd and Sendmail could be using pwcheck. Note that I'm not saying this is necessarily a bad idea--I'm just trying to clarify the facts. I hope this is clear enough. For saslauthd, all you need to write is a single function which takes the username, password, service and realm as args, verifies against the LDAP server and returns a response string. saslauthd has a plug-in interface which can be used to add any mechanism to those already existing in saslauthd. The biggest difference is that implementers to NOT have to worry about the wire-protocol. Yes I'm well of this. In fact my upcoming Perl pwcheck framework will offer exactly the same functionality. The differences will be that: - It will use Net::Server underneath which means a choice of fork-on-demand, preforking, or single process daemon models - No re-compilation to add/change mechs because it's Perl - Plug-ins written in Perl rather than C I would consider the pwcheck support in SASL v2 for backwards compatibility only. If I were going to write a new authentication module/mechanism, I would do so using the saslauthd framework. Mainly because I only need to write a single protocol-agnostic function to interface with saslauthd. Just my $.02 Ken -- 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
Re: FAQ: What is saslauthd?
I want to pipe up here and clarify my original intent and statements. Some posters where asking about saslauthd; what it was, were it could be found, etc. While it is true that saslauthd can (and will) use a different protocol to communitcate with the SASL library, today in the here and now, pwcheck and saslauthd are interchangeable. If you wish to use some of the more advances capabilities of saslauthd, but not upgrade to the 2.0.x SASL series ( which you should not do ), you can do so. To avoid problems going forward, if you wish to use saslauthd with SASL 1.5.24, use cvs to checkout the version tagged sasl-1_5_27 and use the saslauthd deamon found there. - Original Message - From: Ken Murchison [EMAIL PROTECTED] To: Jeremy Howard [EMAIL PROTECTED] Cc: Christopher Audley [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, September 14, 2001 9:51 AM Subject: Re: FAQ: What is saslauthd? Your statement above is NOT correct. pwcheck and saslauthd are completely independent of one another, and can (and will) use different protocols (check the SASL v2 source). If you look at configure.in, nothing prevents you from compiling support for both into a single SASL library. This means (in theory) that Cyrus could be using saslauthd and Sendmail could be using pwcheck.
Re: FAQ: What is saslauthd?
I want to pipe up here and clarify my original intent and statements. Some posters where asking about saslauthd; what it was, were it could be found, etc. While it is true that saslauthd can (and will) use a different protocol to communitcate with the SASL library, today in the here and now, pwcheck and saslauthd are interchangeable. If you wish to use some of the more advances capabilities of saslauthd, but not upgrade to the 2.0.x SASL series ( which you should not do ), you can do so. To avoid problems going forward, if you wish to use saslauthd with SASL 1.5.24, use cvs to checkout the version tagged sasl-1_5_27 and use the saslauthd deamon found there. - Original Message - From: Ken Murchison [EMAIL PROTECTED] To: Jeremy Howard [EMAIL PROTECTED] Cc: Christopher Audley [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, September 14, 2001 9:51 AM Subject: Re: FAQ: What is saslauthd? Your statement above is NOT correct. pwcheck and saslauthd are completely independent of one another, and can (and will) use different protocols (check the SASL v2 source). If you look at configure.in, nothing prevents you from compiling support for both into a single SASL library. This means (in theory) that Cyrus could be using saslauthd and Sendmail could be using pwcheck.
Re: FAQ: What is saslauthd?
cc'd to cyrus-sasl Ken Murchison wrote: ...rather long thread where Ken and I confuse each other greatly snipped... One of the two of us is either confused or not being clear. Let's try to put this thread to rest :^) Sorry, no such luck yet :-( You can reply to this off-list if you think this is getting out of control--although so far we seem to be getting somewhere so maybe the discussion is good for the archives... Your statement above is NOT correct. pwcheck and saslauthd are completely independent of one another, and can (and will) use different protocols (check the SASL v2 source). If you look at configure.in, nothing prevents you from compiling support for both into a single SASL library. This means (in theory) that Cyrus could be using saslauthd and Sendmail could be using pwcheck. According to Christopher Audley in the message: http://asg.web.cmu.edu/archive/message.php?mailbox=archive.info-cyrusmsg=10 234: To the core sasl library, it looks just like pwcheck. Open a UNIX socket, pass in 'username\0password\0' and get back 'OK' or something else. saslauthd defaults to putting its socket in a different location from pwcheck, but it has a command line switch you can use to emulate pwcheck behavior. Because the protocol is essentially the same as pwcheck, you can lift saslauthd from a latter version of SASL and use it with your 1.5.24 SASL installation Sure, you can compile support for both, but all that means is you can have two different unix sockets for two different SASL-using apps. Of course Christopher's description above now needs to be updated to say pass in 'countusernamecountpasswordcountservicecountrealm' and get back '2OK' or something else. Now if we do change to that different wire protocol, I strongly suggest that it be changed for both the saslauthd _and_ the pwcheck sockets. Making that different would just be confusing, and would mean that pwcheck daemons would not be able to take advantage of the realm and service parameters. I would consider the pwcheck support in SASL v2 for backwards compatibility only. Maybe we need a distinction between pwcheck-socket-support which is the ability to tell SASL to contact a Unix socket to authenticate, versus pwcheck-shadow-daemon which is the pwcheck daemon that comes with SASL 1.x for authenticating against the shadow file. The pwcheck-shadow-daemon is clearly redundent with saslauthd, because it is less flexible and less scalable. The pwcheck-socket-support is (I don't think) for backwards compatibility only. It is the very wire protocol that saslauthd uses. If I were going to write a new authentication module/mechanism, I would do so using the saslauthd framework. Mainly because I only need to write a single protocol-agnostic function to interface with saslauthd. If I were going to write a new authentication module/mechanism, I would do so using the Perl-pwcheck framework. With this I only need to write a single protocol-agnostic function to interface with the Perl-pwcheck framework. I also get the benefits I mentioned in my last message (choice of forking models, no re-compilation, use of Perl rather than C). Note that this framework is not released yet, since I want to clarify these issues as they may effect the interface of Perl-pwcheck.
Re: FAQ: What is saslauthd?
Jeremy Howard wrote: Ken Murchison wrote: Christopher Audley wrote: ... Because the protocol is essentially the same as pwcheck, you can lift saslauthd from a latter version of SASL and use it with your 1.5.24 SASL installation. Well... This is *most likely* going to change in SASL v2. The current thinking between myself, Lyndon Nerenberg from Messaging Direct (the original author of saslauthd), and Rob Siemborski and Larry Greenfield from CMU, is that the protocol will be changed to use counted length strings instead of NUL delimited strings, and will be extended to include the service name and user realm. An example from Lyndon is below. Why the proposed change, Ken? The current null termination is easy to use and existing daemons already work with it. Not _entirely_ sure myself. This was proposed by the guy who originally authored (and contributed) saslauthd. My guess is that using counted length strings (similar to IMAP's literals) is much cleaner, especially if we define the string content as UTF-8. I can understand the interest in adding the service name, and I'd sure I'd understand why 'realm' is useful if you could explain briefly what that is... But I don't see the point of changing the format. I wanted the service name so that any PAM implementations which have different rules for POP and IMAP will still work (like mine). I then decided to add the realm (currently only used by Kerberos) so that all the data currently used internally by SASL v1.5 for plaintext verification is available to whichever mechanism is used by saslauthd. Hey, it's no big deal--I'm sure I can handle counting characters ;-) But if it ain't broke, don't fix it, huh? I think this is more of a move forward and a preemptive thing. Let's change it now before we realize that it is broken down the road. Ken -- 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
Re: FAQ: What is saslauthd?
Jeremy Howard wrote: Ken Murchison wrote: Christopher Audley wrote: ... Because the protocol is essentially the same as pwcheck, you can lift saslauthd from a latter version of SASL and use it with your 1.5.24 SASL installation. Well... This is *most likely* going to change in SASL v2. The current thinking between myself, Lyndon Nerenberg from Messaging Direct (the original author of saslauthd), and Rob Siemborski and Larry Greenfield from CMU, is that the protocol will be changed to use counted length strings instead of NUL delimited strings, and will be extended to include the service name and user realm. An example from Lyndon is below. Why the proposed change, Ken? The current null termination is easy to use and existing daemons already work with it. Now that I think about it, what's the difference? The pwcheck capability is not going away, so anything you have already written will still work. With saslauthd, the daemon itself speaks the protocol, NOT the backend mechanism. As long as the API for mechanisms doesn't change (which it will/has in the SASL v2 code), we should be able to change the protocol all day long without breaking the plug-in code. Ken -- 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
Re: FAQ: What is saslauthd?
Ken Murchison wrote: Hey, it's no big deal--I'm sure I can handle counting characters ;-) But if it ain't broke, don't fix it, huh? I think this is more of a move forward and a preemptive thing. Let's change it now before we realize that it is broken down the road. I guess it's the old in-band vs. out-of-band signalling thing. Squid's external authenticators communicated in a similar way, and had an issue when someone figured out how to inject \n's (Squid's string separators) into the string. -- Regards, Daryl Tester, Software Wrangler and Bit Herder, IOCANE Pty. Ltd. Now is the Winter of our Discount Tent. -- The Red Green Show
Re: FAQ: What is saslauthd?
Ken Murchison wrote: Jeremy Howard wrote: Ken Murchison wrote: Now that I think about it, what's the difference? The pwcheck capability is not going away, so anything you have already written will still work. With saslauthd, the daemon itself speaks the protocol, NOT the backend mechanism. As long as the API for mechanisms doesn't change (which it will/has in the SASL v2 code), we should be able to change the protocol all day long without breaking the plug-in code. Sorry if I displaying ignorance here, but I was under the impression that saslauthd is simply a daemon that _does_ use the pwcheck API, except that the SASL configure script happens to set it up to use a different Unix socket to normal. So if saslauthd is using char-counted strings (which I now understand from Lyndon's message may reduce security problems) then the pwcheck interface must be changed to use these strings. Which means that daemons already written will have to be changed to use the new string format. Disclaimer: I have never used/implemented pwcheck, so please verify what I say, and corretc me if necessary. If by API, you mean the wire-protocol, then pwcheck and saslauthd _used_ to be the same, but I don't consider that an API. AFAIK, pwcheck doesn't have an API, where saslauthd does (even though the guts of both is very similar). Yes, by API I mean wire-protocol. And my understanding is that saslauthd is simply a daemon that uses the pwcheck wire-protocol under the surface. There will not be separate pwcheck and saslauthd wire-protocols--although the configure script for SASL will use a different port for the saslauthd daemon. Therefore the changing of the wire protocol will effect existing pwcheck daemons. Note that I'm not saying this is necessarily a bad idea--I'm just trying to clarify the facts. For saslauthd, all you need to write is a single function which takes the username, password, service and realm as args, verifies against the LDAP server and returns a response string. saslauthd has a plug-in interface which can be used to add any mechanism to those already existing in saslauthd. The biggest difference is that implementers to NOT have to worry about the wire-protocol. Yes I'm well of this. In fact my upcoming Perl pwcheck framework will offer exactly the same functionality. The differences will be that: - It will use Net::Server underneath which means a choice of fork-on-demand, preforking, or single process daemon models - No re-compilation to add/change mechs because it's Perl - Plug-ins written in Perl rather than C
Re: FAQ: What is saslauthd?
On Tuesday 11 September 2001 21:19, Jeremy Howard wrote: Having said that, the argument that pwcheck is practically useless still doesn't make sense. Access to the pwcheck socket can be restricted to the Cyrus user, and as a unix socket it is only accessible if you have local access to the machine. So if you have local access to the machine _and_ access to the Cyrus account, you can mount a password guessing attack on the shadow file. Hardly a huge problem, although I think I will add a pause into my preforking Perl daemon framework as a precaution. I'll announce this on the list when it's done. Let me clarify my assertion. My reasoning is this: if a privileged daemon adds no functionality nor security to the system, why run it? That is why I called pwcheck practically useless. Once again: access to pwcheck's socket is comparable to read access to /etc/shadow. Any local user can mount a dictionary attack at full speed unless the socket's access is restricted. Giving the Cyrus account access to the pwcheck socket is equivalent to giving the Cyrus account read access to /etc/shadow. So why use pwcheck at all? It's another privileged daemon to worry about. The shadow group method gives equivalent security without needing a daemon. If retry slowdown is added to pwcheck/saslauthd, however, then it would have behavior much like /bin/su (which is public). Applications like cyrus-imap would not need special permissions to access pwcheck. Only pwcheck/saslauthd would need special privileges in this case. That is why I believe adding a retry slowdown like what you are doing is a good thing. Chris
Re: FAQ: What is saslauthd?
From: Christopher Wong [EMAIL PROTECTED] Date: Wed, 12 Sep 2001 12:09:54 -0400 Let me clarify my assertion. My reasoning is this: if a privileged daemon adds no functionality nor security to the system, why run it? That is why I called pwcheck practically useless. Once again: access to pwcheck's socket is comparable to read access to /etc/shadow. Any local user can mount a dictionary attack at full speed unless the socket's access is restricted. Giving the Cyrus account access to the pwcheck socket is equivalent to giving the Cyrus account read access to /etc/shadow. So why use pwcheck at all? It's another privileged daemon to worry about. The shadow group method gives equivalent security without needing a daemon. This isn't true. If you can't detect an _on-line_ dictionary attack you have a serious problem. This is very different from being able to read /etc/shadow. What threat model are you worried about right now? Someone breaking into the Cyrus account and stopping them from being root? Someone with a local account attempting to elevate their privs but without access to the Cyrus account? And what is the threat model that allows you to not worry about the use of plaintext passwords over the wire? Larry
Re: FAQ: What is saslauthd?
On Monday 10 September 2001 18:26, Christopher Audley wrote: saslauthd is an evolution of pwcheck available with the 1.5.27 and 2.0.x versions of the sasl library (available from CVS). Saslauthd basically takes the core of pwcheck and adds forking so that each request is handled by a different subprocess, and password checking logic modules have been added for more methods. Its a start in the right direction, but much more needs to be done. For instance, the forking of processes is done after an accept, so on servers that see a light load, saslauthd will actually appear to be slower than pwcheck. There is also no limit on how many processes saslauthd will fork, so it introduces new possibilities for DOS attacks. Thanks. Does it slow down retries in the case of unsuccessful attempts? Otherwise, it would be as vulnerable to password guessing as pwcheck is. That weakness of pwcheck makes it practically useless: access to its port is comparable to read access to /etc/shadow and must be restricted accordingly. That makes pwcheck redundant. On the other hand, if forking is unlimited then a user might use saslauthd to guess numerous passwords in parallel. Consequently, slowing down retries may not be enough. Could you explain how saslauthd addresses these issues? Again, thanks. Chris
Re: FAQ: What is saslauthd?
On Tue, 11 Sep 2001 17:56:08 -0400, Christopher Wong [EMAIL PROTECTED] (cw) writes: cw Thanks. Does it slow down retries in the case of unsuccessful attempts? What about other SASL methods? Do they slow down and/or lock out repeated guessing attacks? Don't know. I imagine adding something like this to saslauthd wouldn't be too difficult, but would that be more of a task of imapd/popd? cw On the other hand, if forking is unlimited then a user might use cw saslauthd to guess numerous passwords in parallel. Consequently, cw slowing down retries may not be enough. Could you explain how saslauthd cw addresses these issues? Well, they do have to connect in via imapd/popd first, right? I believe there has already been a request put out to allow for setting instance limits for the various services. Perhaps that up-front upper limit would be sufficient. -- Amos
Re: FAQ: What is saslauthd?
From: Christopher Wong [EMAIL PROTECTED] Date: Tue, 11 Sep 2001 17:56:08 -0400 [...] Thanks. Does it slow down retries in the case of unsuccessful attempts? Otherwise, it would be as vulnerable to password guessing as pwcheck is. That weakness of pwcheck makes it practically useless: access to its port is comparable to read access to /etc/shadow and must be restricted accordingly. That makes pwcheck redundant. Please stop just rnadomly suggesting things. The unix domain socket that is used by pwcheck/saslauthd can be protected to only the Cyrus user, preventing any other Unix user access to it, even if you do allow users to log into the system. Generally, /etc/shadow isn't there to stop on-line password guessing, it's to stop someone from downloading the crypts and running off-line dictionary attacks. On the other hand, if forking is unlimited then a user might use saslauthd to guess numerous passwords in parallel. Consequently, slowing down retries may not be enough. Could you explain how saslauthd addresses these issues? The imapd process slows down on bad passwords, but nothing in the base code stops someone from opening large number of IMAP connections, but such an attack is very obvious. Larry
Re: FAQ: What is saslauthd?
Lawrence Greenfield wrote: From: Christopher Wong [EMAIL PROTECTED] Date: Tue, 11 Sep 2001 17:56:08 -0400 [...] Thanks. Does it slow down retries in the case of unsuccessful attempts? Otherwise, it would be as vulnerable to password guessing as pwcheck is. That weakness of pwcheck makes it practically useless: access to its port is comparable to read access to /etc/shadow and must be restricted accordingly. That makes pwcheck redundant. Please stop just rnadomly suggesting things. The unix domain socket that is used by pwcheck/saslauthd can be protected to only the Cyrus user, preventing any other Unix user access to it, even if you do allow users to log into the system. Generally, /etc/shadow isn't there to stop on-line password guessing, it's to stop someone from downloading the crypts and running off-line dictionary attacks. I think that Christopher's point is that someone with access to the pwcheck socket could use it to mount a password attack, since pwcheck doesn't pause after an unsuccessful login. In that sense it is true that access to its port is comparable to read access to /etc/shadow and must be restricted accordingly. Access to the pwcheck port is only required for the Cyrus user though, so there is no problem for a pwcheck daemon that correctly sets the permissions for the socket. On the other hand, if forking is unlimited then a user might use saslauthd to guess numerous passwords in parallel. Consequently, slowing down retries may not be enough. Could you explain how saslauthd addresses these issues? I don't know about saslauthd, but the approach I use in my Perl-based pwcheck daemon is to use a preforking approach with a limit on the maximum number of processes. The imapd process slows down on bad passwords, but nothing in the base code stops someone from opening large number of IMAP connections, but such an attack is very obvious. For someone with access to the pwcheck socket imapd's behaviour is not relevent (and Chris mentioned that his concern is access to the socket). What matters is the behaviour of the pwcheck or saslauthd daemon. Having said that, the argument that pwcheck is practically useless still doesn't make sense. Access to the pwcheck socket can be restricted to the Cyrus user, and as a unix socket it is only accessible if you have local access to the machine. So if you have local access to the machine _and_ access to the Cyrus account, you can mount a password guessing attack on the shadow file. Hardly a huge problem, although I think I will add a pause into my preforking Perl daemon framework as a precaution. I'll announce this on the list when it's done.
Re: FAQ: What is saslauthd?
The point is that you can come up with an infinite number of vulnerabilities as a result of misconfiguration. The second point is that you can not assert sasldauthd/pwcheck creates denial of service attacks or is insecure without considering the services that uses it. Walter
