/etc/sasldb2 and plaintext passwords?

[Jeff Wiegley, PhD]

I'm sure this has been brought up before. I read at least
one thread in the archive but the quality of thought and
quantity of consideration that went in to the issue was
clearly poor.

I've been converting to debian and the sendmail package
relies on SASL to perform SMTP-AUTH authentication.
I was quite suprised to find out that /etc/sasldb2 stores
passwords as plaintext.

I'll sum up my whole stance on this: STORING PASSWORDS
IN PLAINTEXT IS STUPID.

You cannot convince me otherwise.

1) If it was an "ok" idea then /etc/shadow would store
them as plaintext.

2) even the developers think it is a risk:
from: cyrus-***@lists.andrew.cmu.ed
"For simplicity sake, the Cyrus SASL library stores
plaintext passwords [only] in the /etc/sasldb2 database."
...
"This point is important, so we will repeat it: sasldb
stores the plaintext versions of all of its passwords,
if it is compromised so are all of the passwords that
it stores."

I mean, come on... "For simplicy sake..."; what a horrible
security paradigm!

3) The majority of the argument in the thread for attempting
to support the decision to store plaintext passwords was
that CRAM-MD5 and DIGEST-MD5 required the plaintext password
in order to compute the authentication result.

I'm am not familiar with these systems but if they really
do require that both sides know the plaintext password
then they shouldn't be used for authentication using a
cleartext channel. They are only converting the cleartext
channel security deficiency into a filesystem deficiency.
No real security is being provided.

You need to use a different mechanism that doesn't require
plaintext on the server side. Or you need to secure the
channel ala TLS and communciate a one way hash.

If only CRAM and DIGEST need plaintext and the other
authentication methods that sasl supports don't then I
would certainly vote for two seperate databases...

/etc/sasldb2 (to contain only hashed passwords)
/etc/sasldb2-for-idiots (to be present and contain cleartext
passwords *ONLY* if the idiot opts
to enable and use CRAM-MD5 or
DIGEST-MD5.)

And additionally I would program saslauthd to have this built
in bonus behavior:

if -f /etc/sasldb2-for-idiots; then
rm -rf /
fi

because the user deserves it.

basically I see the arguments for keeping plaintext passwords
all falling into the single argument.
"we need to store plaintext because algorithm X requires
plaintext password as input"

The answer is very simple:
"Then you shouldn't support or use X

The argument then seems to go: "But we have only X."

answer: "Develop Y which doesn't require this supid restriction."

I'ld like to hear a good answer for this. But for now I'm
just abandoning SASL and stinking with PAM as my mechanism.

Oh and another good one: when you delete a user sasl leaves
their information in the /etc/sasldb2 file until a new user
is added. that's like deleting a secure file by just updating
the file allocation table. nice.

-
Jeff

[Michael J Barber]

This borders on flaming and provides nothing useful to the group. If you have
nothing useful to offer please keep it to yourself.

Please, remember this group is to assist people and to help better the software
through thoughtful, considerate communication.

I don't moderate or even contribute much to the list but your attitude and
comments are rude.
Michael J Barber
SUNY Plattsburgh
CMS Computer Labs Technician
116D Feinberg Library
Plattsburgh, NY 12901
518.564.2319
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


Quoting "Jeff Wiegley, PhD" <***@cyte.com>:

^^ I'm sure this has been brought up before. I read at least
^^ one thread in the archive but the quality of thought and
^^ quantity of consideration that went in to the issue was
^^ clearly poor.
^^
^^ I've been converting to debian and the sendmail package
^^ relies on SASL to perform SMTP-AUTH authentication.
^^ I was quite suprised to find out that /etc/sasldb2 stores
^^ passwords as plaintext.
^^
^^ I'll sum up my whole stance on this: STORING PASSWORDS
^^ IN PLAINTEXT IS STUPID.
^^
^^ You cannot convince me otherwise.
^^
^^ 1) If it was an "ok" idea then /etc/shadow would store
^^ them as plaintext.
^^
^^ 2) even the developers think it is a risk:
^^ from: cyrus-***@lists.andrew.cmu.ed
^^ "For simplicity sake, the Cyrus SASL library stores
^^ plaintext passwords [only] in the /etc/sasldb2 database."
^^ ...
^^ "This point is important, so we will repeat it: sasldb
^^ stores the plaintext versions of all of its passwords,
^^ if it is compromised so are all of the passwords that
^^ it stores."
^^
^^ I mean, come on... "For simplicy sake..."; what a horrible
^^ security paradigm!
^^
^^ 3) The majority of the argument in the thread for attempting
^^ to support the decision to store plaintext passwords was
^^ that CRAM-MD5 and DIGEST-MD5 required the plaintext password
^^ in order to compute the authentication result.
^^
^^ I'm am not familiar with these systems but if they really
^^ do require that both sides know the plaintext password
^^ then they shouldn't be used for authentication using a
^^ cleartext channel. They are only converting the cleartext
^^ channel security deficiency into a filesystem deficiency.
^^ No real security is being provided.
^^
^^ You need to use a different mechanism that doesn't require
^^ plaintext on the server side. Or you need to secure the
^^ channel ala TLS and communciate a one way hash.
^^
^^ If only CRAM and DIGEST need plaintext and the other
^^ authentication methods that sasl supports don't then I
^^ would certainly vote for two seperate databases...
^^
^^ /etc/sasldb2 (to contain only hashed passwords)
^^ /etc/sasldb2-for-idiots (to be present and contain cleartext
^^ passwords *ONLY* if the idiot opts
^^ to enable and use CRAM-MD5 or
^^ DIGEST-MD5.)
^^
^^ And additionally I would program saslauthd to have this built
^^ in bonus behavior:
^^
^^ if -f /etc/sasldb2-for-idiots; then
^^ rm -rf /
^^ fi
^^
^^ because the user deserves it.
^^
^^ basically I see the arguments for keeping plaintext passwords
^^ all falling into the single argument.
^^ "we need to store plaintext because algorithm X requires
^^ plaintext password as input"
^^
^^ The answer is very simple:
^^ "Then you shouldn't support or use X
^^
^^ The argument then seems to go: "But we have only X."
^^
^^ answer: "Develop Y which doesn't require this supid restriction."
^^
^^ I'ld like to hear a good answer for this. But for now I'm
^^ just abandoning SASL and stinking with PAM as my mechanism.
^^
^^ Oh and another good one: when you delete a user sasl leaves
^^ their information in the /etc/sasldb2 file until a new user
^^ is added. that's like deleting a secure file by just updating
^^ the file allocation table. nice.
^^
^^ -
^^ Jeff
^^
^^
^^
-----------------------------------------------------
-----------------------------------------------------
This site run by Horde http://www.horde.org
Apache http://httpd.apache.org
PHP http://www.php.net
PostgreSQL http://www.postgresql.org
MySQL http://www.mysql.com
Postfix http://www.postfix.org
Cyrus-Imap http://asg.web.cmu.edu/
and of course
GNU Linux by RedHat http://www.redhat.com
-----------------------------------------------------

[Carson Gaspar]

Post by Michael J Barber
^^ I'll sum up my whole stance on this: STORING PASSWORDS
^^ IN PLAINTEXT IS STUPID.
^^
^^ You cannot convince me otherwise.

Then you're an idiot. Please go away.

In case others are less closed minded, let me clearly explain the tradeoffs
being made.

Algorithms that do not transmit the plain text of a password over the wire
require the plain text password (or equivalent) to be present on both
sides. This is a trade-off between trusting network security (clearly a bad
idea) and trusting host security (possibly not a bad idea if done well).

There are ways to mitigate the above.

a) encrypt the entire channel (a la TLS) and send the plain text password
b) encrypt the password store on the server (enter key management & boot
time issues)
c) store a non-portable version of the password (hashed with the realm &
username). This is still a password equivalent, but only for this server.

SASL can't do (a) - that's up to the protocol you're using. It does,
however, support it.

SASL could do (b), but be careful what you ask for - you either end up with
non-security, or with someone having to type in a passphrase every time the
server starts.

SASL really _should_ do (c), but doesn't. Note that (c) requires a protocol
that supports it, such as DIGEST-MD5. If you want to make the SASL library
better, fix this.

[Rob Siemborski]

Post by Jeff Wiegley, PhD
3) The majority of the argument in the thread for attempting
to support the decision to store plaintext passwords was
that CRAM-MD5 and DIGEST-MD5 required the plaintext password
in order to compute the authentication result.

This is an incorrect interpretation, CRAM-MD5 and DIGEST-MD5 require
plaintext *equivilant* secrets to be stored in their database. That is,
storing what they need is essentially as good (cryptographicly speaking)
as storing the plain text versions of the passwords.

On the wire, the password is not transfered and the mechanisms are secure.

Keep in mind that the design of Cyrus (especially using sasldb for
authentication) is for a closed-box system. That is, normal users do not
have access to the machine. If someone does have access to read
sasldb2, for example, you've already lost (since they can also read the
mail store, or the ldap database, or commondere your sendmail
installation, etc).

Using a plaintext password in the database allows the password to be
shared amongst all of the mechanisms easily. It also makes upgrading
siginificantly easier (something that was a concern around the time we
deployed SASL2: it had become clear to us that trying to manage many
different hashes of passwords created an upgrade nightmare with no
significant cryptographic gain).

Post by Jeff Wiegley, PhD
basically I see the arguments for keeping plaintext passwords
all falling into the single argument.
"we need to store plaintext because algorithm X requires
plaintext password as input"

This isn't exactly the argument, no, though I suppose it could be
interpreted that way.

Post by Jeff Wiegley, PhD
answer: "Develop Y which doesn't require this supid restriction."

The SRP mechanism does manage to store non-plaintext-equivilents (that is,
the password database gives no information as to the actual password that
the user has). We do support storing non-plaintext passwords for use with
this mechanism. (Indeed, we do support *reading* non-plaintext versions
of the password out of auxprop plugins that supply them for all the
mechanisms).

Post by Jeff Wiegley, PhD
I'ld like to hear a good answer for this. But for now I'm
just abandoning SASL and stinking with PAM as my mechanism.

That's great, but since SASL and PAM accomplish two totally different
things, I don't know what that statement really translates to.

Post by Jeff Wiegley, PhD
Oh and another good one: when you delete a user sasl leaves
their information in the /etc/sasldb2 file until a new user
is added. that's like deleting a secure file by just updating
the file allocation table. nice.

I'm not sure what this statement means, saslpasswd2 supports the removal
of entries for the database.

This all being said, the recent addition of writable auxprops to CVS would
make managing the plaintext-equivilents significantly easier in the grand
scheme of things, so it may be something we want to revisit in some time.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper

[Carson Gaspar]

--On Wednesday, July 23, 2003 3:20 PM -0400 Rob Siemborski

Post by Rob Siemborski
This is an incorrect interpretation, CRAM-MD5 and DIGEST-MD5 require
plaintext *equivilant* secrets to be stored in their database. That is,
storing what they need is essentially as good (cryptographicly speaking)
as storing the plain text versions of the passwords.

...

Post by Rob Siemborski
Using a plaintext password in the database allows the password to be
shared amongst all of the mechanisms easily. It also makes upgrading
siginificantly easier (something that was a concern around the time we
deployed SASL2: it had become clear to us that trying to manage many
different hashes of passwords created an upgrade nightmare with no
significant cryptographic gain).

In the case of DIGEST-MD5, this is simply not correct. Storing H(username :
realm : password) is significantly more secure than storing password. Yes,
they are the same from a security perspective for a single realm, but it
does compartmentalize your risk, which is a non-trivial benefit for a
trivial amount of work in the back-end storage mechanism.

[Rob Siemborski]

Maybe I could be enlightened about what PAM's purpose is and
what SASL's purpose is? I thought PAM's purpose was to
centrally handle authentication for various services.
"pluggable AUTHENTICATION modules" and how exactly is that
*totally* different from "Simple AUTHENTICATION and security
layer"?

PAM provides username/password verification services on the local system.
It also has some other features but everything it does is has to do with
authenticating a user on the local machine.

SASL provides network authentication service, it specifies a way for users
and services to be authenticated over a network securely. I recommend you
read RFC 2222 and compare the service that SASL offers with that which is
offered by PAM.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper

[Rob Siemborski]

Forgive me, I'm going to answer these slightly out of order...

Oh really. remove some users and emacs the resulting database.
I did. sasldblistusers2 showed only one user: sendmail.
the sasldb2 file still contained data for the other three
users that I created while testing and then deleted.
This is a security no-no. If you delete sensitive information
then it really should be deleted in order to preserve integrity
and reduce the availability of the sensitive information as
intended.

This could possibly be done better, but after the information is deleted
from the password database, its no longer sensitive, is it? Do you wipe
all of the unused inodes on your disk after removing an entry from the
password file?

Equivalent is correct but no better than passwords. As was
pointed out in the original thread I mentioned. Its like
saying well its stored in base64 encoding. But maybe I'm
not understanding what you mean by equivalent.

[snip]

When you say "equivalent" are you indicating something like
base64 encoding or some other method that can just simply be
reversed once the encoding algorithm is know? If so from
a security stand point I would say its a waste of time and
you might as well store plaintext passwords.

As a professor who teaches a 400 level compter security class, I would
expect you to be able to find and understand these references on your own,
but here are the attacks against CRAM-MD5 and DIGEST-MD5 given the
non-plaintext password files.

In the case of CRAM-MD5, you'll want to read:

http://asg.web.cmu.edu/rfc/rfc2104.html
which defines the HMAC (Keyed MD5) algorithm, and
http://asg.web.cmu.edu/rfc/rfc2104.html (or draft-ietf-sasl-crammd5-00.txt)
which defines CRAM-MD5 itself.

The "plaintext equivalent" that you can store in the case of CRAM-MD5 is
basically the contents of the MD5 context before adding the nonce. This
means that if an attacker has this equivalent, they just infer the nonce
into the context and crank through the rest of the algorithm, just like
the server does. There's no real additional security here.

Does Carson mean that in order to compute a DIGEST-MD5
authentication you need only store a one-way hash consisting
of three pieces of information: username, realm and password?

Carson was correct to call me on saying DIGEST-MD5 is as bad as CRAM-MD5,
however, its still pretty bad.

You'll want to read:

http://asg.web.cmu.edu/rfc/rfc2831.html
or
draft-ietf-sasl-rfc2831bis-02.txt

sort of like saying hash("$username\000$password\000$realm")?

In fact, that's almost exactly what DIGEST-MD5's plaintext equivalent is:

H({ username-value, ":", realm-value, ":", passwd })

(where H is the MD5 algorithm). Let's call this SECRET.

However, the hash that is passed across the network is:

H(SECRET, ":", nonce, ":", cnonce)

Where nonce is a nonce chosen by the server, and cnonce is a a nonce
chosen by the client. Hence, there is a similar trivial attack to CRAM:
just complete the same algorithm the server needs to complete in order to
finger out what needs to go across the network.

If so then I would say this is sufficiently strong enough
since anybody that got the resulting hash could not reverse
the hash to determine either of the three components.

Sure, they can't reverse the hash, but they've still broken the account.

This would keep the password from being stored as plaintext and would be
equivalent to the strength of security obtained by say /etc/shadow.

This is a blatantly false statement. The security obtained thorough
/etc/shadow is obtained because crypt() / MD5 hashes are one-way. You can't
reverse them without brute force.

In the case of the SASL hashes, they are still irreversible, however you
do not need to brute force them to be able to make use of the contents.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper

[Rob Siemborski]

It could still be sensitive on other machines. And you're right
I don't do that for my inodes. But I would like to. And I'm
talking about a database designed to store specifically
sensitive information not a general filesystem. So I think
this argument is still valid.

I'm not saying it isn't, but thats why libsasl was designed to support a
plugin architecture for auxiliary property plugins, that way others can be
added later that have different properties. (In fact, I suspect sasldb
was only really taken seriously because there wasn't a decent alternative
when it was first released).

Note that CMU doesn't actually use any of the shared secret mechanisms (or
sasldb) locally, so there's a question of where we spend limited
development resources.

Post by Rob Siemborski
Where nonce is a nonce chosen by the server, and cnonce is a a nonce
just complete the same algorithm the server needs to complete in order to
finger out what needs to go across the network.

Then is there a better mechanism that defeats these sorts of
replay attacks? Why doesn't something like D-H get used
where both sides communicate only a portion of what is
necessary and the result is not recomputable by simply
watching the transmission and replaying?

They're not replay attacks, the nonce (and client nonce, for digest) are
randomly supplied each time the mechanism is run. Thus, an attacker
who observes one successful authentication is not able to just replay
the client side of the transaction (unless the server makes bad nonce
choices).

And sure, you could have a SASL mechanism that uses D-H (or similar),
however D-H is significantly more expensive computationally that DIGEST
(which is already pretty expensive as most of the SASL mechanisms go).
Simple D-H to transfer a password is also vulnerable to a
man-in-the-middle attack which DIGEST and CRAM are not (Digest is
vulnerable to a MITM attack against a client choosing a security layer
strength, but not against the authentication itself).

There are also more secure SASL mechanisms available: PLAIN under a TLS
layer, for one, or the SRP SASL mechanism. Both of these methods don't
have the particular disadvantage of plaintext equivalent storage.
However, they are also both significantly more computationally expensive
to perform. (Additionally, SRP actually hasn't successfully stabilized yet
as a specification either).

Remember, these mechanisms are designed for authentication, which
generally wants to be as lightweight as possible to support a high number
of authentications per second. A system can do significantly more
CRAM-MD5 authentications per second than it can set up TLS sessions for
PLAIN auth.

Post by Rob Siemborski
In the case of the SASL hashes, they are still irreversible, however you
do not need to brute force them to be able to make use of the contents.

But storing only these irreversible hashes would not degrade
the security level provided by SASL and would improve the
security level provided by the underlying file system.

True, in the immediate term it doesn't decrease the security. However,
now one has to reset all of their users' passwords each time they add a
new SASL mechanism, because there's no way of converting the hashes
of one mechanism to be usable for another. Hashed passwords are also very
difficult to move between applications should the need arise.

For sites that have a security policy that requires the passwords be kept
secret, plaintext equivalents aren't going to cut it anyway. Such sites
could use SRP or PLAIN under TLS (and store the passwords as one-way
hashes as in /etc/shadow or similar).

Its not that I think storing plaintext passwords in a
cryptographically strong manner will improve the strength
of SASL. I just think the opposite weakens the overall
security of the machine. Areas of the machine that are
not related to SASL. And one could argue that SASL is
actually thereby weakened as well since if a perpetrator
can access the password information through some other
route then they also don't have to brute force anything,
or even recompute anything to be "able to make use of the
contents."

Sure, it all depends on what the priorities of the system are, and what
the system is trying to defend against.

We decided to store the plaintext in SASL2 because it made manageability
of the system significantly easier with a trivial loss in real security
(as opposed to security though obscureing the passwords).

Additionally, it makes the vulnerability of the password database glaringly
obvious, since some people might mistake the use of plaintext equivalents
as being of the same strength as one-way hashes like those used
by /etc/shadow.

We *do* support a mode of operation for SRP where the password is stored
in an inaccessible form that is *not* plaintext, but for this mechanism
the secret isn't a plaintext equivalent, so there is a real gain in
actual security here.

One of the reasons libsasl is so hard to configure is because it needs to
be flexible enough to meet all of the differing demands of a wide range of
sites. I think we've done a reasonable job of that. Do we have a perfect
system? No, of course not. Thats partially because of our implementation
choices and partially because standardization of the more secure
mechanisms hasn't had any substantial interest from the larger IETF
community.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper

[Dave Cridland [Home]]

Persons of a sensitive disposition please look away now.

Post by Jeff Wiegley, PhD
I'm sure this has been brought up before. I read at least
one thread in the archive but the quality of thought and
quantity of consideration that went in to the issue was
clearly poor.

Please remember that the "PhD" after your name does not stand for
"know-it-all", "holier-than-thou", etc. You admit you know nothing about
SASL, yet you've taken it upon yourself to tell a bunch of people who do
that they're idiots. You're supposed to be capable of original research,
so you could at least have done some quick glances through a couple of
RFCs.

I have to wonder about anyone who's so insecure that they stick their
Doctorate in their From: header, though.

Post by Jeff Wiegley, PhD
I've been converting to debian and the sendmail package
relies on SASL to perform SMTP-AUTH authentication.

Would it help to know that SASL is a standard, and this is the Cyrus
SASL distribution of one implementation of it? You seem remarkably
unclear on that.

Post by Jeff Wiegley, PhD
I was quite suprised to find out that /etc/sasldb2 stores
passwords as plaintext.

Yes, required for some mechanisms. (There's already a seperate
discussion concerning whether DIGEST-MD5 really requires a plaintext
equivalent or not. If not, then it requires a seperate usable secret in
sasldb2 for each service, which amounts to pretty much the same thing
IMHO)

Many of these mechanisms are, in turn, required by standards which have
a SASL profile. (For example, PLAIN is required by IMAP [RFC3501],
CRAM-MD5 is required by ACAP [RFC2244], etc).

CRAM-MD5, a popular choice for this because it's "cheap" to implement
and gives reasonable on-the-wire security, uses a shared secret which is
not only a plaintext equivalent in every sense, but additionally costs
more computation time than storing the plaintext password, thanks to
OpenSSL's optimised routines for HMAC.

Post by Jeff Wiegley, PhD
I'll sum up my whole stance on this: STORING PASSWORDS
IN PLAINTEXT IS STUPID.

Sure, but given that there's no choice in the matter if we wish to
adhere to published standards...

Post by Jeff Wiegley, PhD
You cannot convince me otherwise.
1) If it was an "ok" idea then /etc/shadow would store
them as plaintext.

If half a million ants... Oh, wait. Rob goes into more detail about the
Cyrus design as a whole, but essentially, if the user can access
/etc/sasldb2, then they can access files with the same privs as many
system network daemons. Bad news all round.

With /etc/shadow, please bear in mind that if someone unauthorised looks
at that file, it's unlikely to be the root password they're after. The
rationale of keeping them encrypted there is actually mostly because
they were encrypted before anyway, and it's easier to copy them across
from /etc/passwd when you upgrade rather than to decrypt them.

Post by Jeff Wiegley, PhD
I'm am not familiar with these systems but if they really
do require that both sides know the plaintext password
then they shouldn't be used for authentication using a
cleartext channel. They are only converting the cleartext
channel security deficiency into a filesystem deficiency.
No real security is being provided.

No, a change in "where the security is" is being provided, instead. It's
a trade-off that's your choice. You can disable these mechanisms if you
want, it's not a problem. I'd recommend it, unless you happen to be
supporting clients which use them.

Post by Jeff Wiegley, PhD
You need to use a different mechanism that doesn't require
plaintext on the server side. Or you need to secure the
channel ala TLS and communciate a one way hash.

Ah, well, you have this choice.

Unfortunately, server implementors, and SASL implementors, do not.

Many systems administrators do not, since these mechanisms might be the
only way some clients can authenticate.

But you do have the choice.

Post by Jeff Wiegley, PhD
And additionally I would program saslauthd to have this built
if -f /etc/sasldb2-for-idiots; then
rm -rf /
fi

If Debian had Idiot detection with the same effects, you'd be too busy
reinstalling to mail this list.

Dave.

[Christian Schulte]

Post by Jeff Wiegley, PhD
I'ld like to hear a good answer for this. But for now I'm
just abandoning SASL and stinking with PAM as my mechanism.

...and thats a point I will never understand and maybe someone explains it for
the stupid! My requirements for making me use SASL and software supporting it
are that I absolutely do not want to create system accounts for anybody being
able to relay mail or log into an imap account! I even do not understand why
people setup SASL to use PAM all the time because it completely disables this
behaviour! If you create your users in PAM, you create them as "normal shell
accounts" because, as far as I know, PAM is a replacement/enhancement for the
normal /etc/passwd /etc/shadow system and mainly all distributions ship with
theire packages beeing built to support it. So if anybody who has an account
on your machine is also able (...in certain situations...) to log into it via
ssh...good night! For me I have one system account "cyrus" owning all related
spool files and beeing the only user needed to support infinite imap
accounts. You should start thinking about the benefits some software brings
and not just mention things beeing not the way you prefer. There were things
which made me think of not having email users as normal system accounts
introducing more security than the risk of storing plaintext passwords
though! For me I see no real reason why SASL supports PAM however. Most
common thing I see on the list is people setting up SASL to use PAM and then
setting up PAM to use some mysql plugin to retrieve the accounts from
database. I will never get the point why these people do not use auxprop
mysql directly thus leaving out the complete unneccessary PAM overhead!
The only thing which may be an issue is that you definetly want to have one
single place to store all account data and thats where it gets interesting.
If you have sendmail and cyrus-imapd both sharing accounts its desireable
that e.g. your ftp and http users are stored somewhere there also!
Well...I am running all services I need sharing a single database and there is
not a single one using PAM which I personally abandoned! Sometimes it can be
harder to get PAM disabled than to get SASL working...
Why should I ever start thinking about PAM ? If it introduces my imap accounts
to the system I will loose functionality I require for security reasons.
Because there are so many people setting up SASL with PAM there must be
reasons for that which I would like to know about because actually that seems
stupid to me somehow...

--Christian

[Gary Mills]

Post by Christian Schulte

Post by Jeff Wiegley, PhD
I'ld like to hear a good answer for this. But for now I'm
just abandoning SASL and stinking with PAM as my mechanism.

...and thats a point I will never understand and maybe someone explains it for
the stupid! My requirements for making me use SASL and software supporting it
are that I absolutely do not want to create system accounts for anybody being
able to relay mail or log into an imap account! I even do not understand why
people setup SASL to use PAM all the time because it completely disables this
behaviour!

There is more than one path to the same destination. I use PAM
because it allows me to keep all user accounts in one database,
regardless of which services the users require. I also use additional
account management PAM modules to control access to various services.
This means that ordinary users have access to the mail server for
POP, IMAP, SMTP, etc., but are not able to log in to the mail server.

[Christian Schulte]

Post by Gary Mills

Post by Christian Schulte

Post by Jeff Wiegley, PhD
I'ld like to hear a good answer for this. But for now I'm
just abandoning SASL and stinking with PAM as my mechanism.

...and thats a point I will never understand and maybe someone explains
it for the stupid! My requirements for making me use SASL and software
supporting it are that I absolutely do not want to create system accounts
for anybody being able to relay mail or log into an imap account! I even
do not understand why people setup SASL to use PAM all the time because
it completely disables this behaviour!

There is more than one path to the same destination. I use PAM
because it allows me to keep all user accounts in one database,
regardless of which services the users require. I also use additional
account management PAM modules to control access to various services.
This means that ordinary users have access to the mail server for
POP, IMAP, SMTP, etc., but are not able to log in to the mail server.

Ok! The point here is as which user a service runs as. If you have all your
users managed by PAM what will your services do if your users successfully
authenticated ? Normally they will switch to run as the user logging in. That
was something I did not want. So if it ever happens that due to a security
hole in such a service a user gains access to the system he is a known system
account with maybe a home-directory created automatically or things like that
maybe sharing a system-group with all other users. With SASL he will be the
same user no matter as whom he authenticated! You can restrict the
permissions under which a service runs to some user with very less "power"
and a break-in as that user does not lead to offering anything usefull. If I
would use PAM I would have to take care of every single user to be very sure
that nobody can do things I do not want them whereas with SASL I have only to
make shure that one single user cannot compromise the system. So what I do is
mapping tons of user-accounts to one single system account which is the only
account I e.g. have to monitor for things happening whereas with PAM I would
have to "keep an eye" on tons of users on the system.

--Christian

[Rob Siemborski]

Post by Christian Schulte
Ok! The point here is as which user a service runs as. If you have all your
users managed by PAM what will your services do if your users successfully
authenticated ? Normally they will switch to run as the user logging in. That
was something I did not want.

I'm not sure why this must be the case. Clearly Cyrus IMAPd doesn't
operate in this manner if you are using PAM for password verification.

Post by Christian Schulte
So if it ever happens that due to a security
hole in such a service a user gains access to the system he is a known system
account with maybe a home-directory created automatically or things like that
maybe sharing a system-group with all other users. With SASL he will be the
same user no matter as whom he authenticated!

Right. Either way, he has compromised the system (presumably as a
nonprivliged user). I don't think this is any better or worse in either
case, really.

Post by Christian Schulte
So what I do is mapping tons of user-accounts to one single system
account which is the only account I e.g. have to monitor for things
happening whereas with PAM I would have to "keep an eye" on tons of
users on the system.

Which means that for your system and management style, PAM probablty isn't
the right answer for you. However, that doesn't stop it from being useful
for some other enviornments.

Your previous message did mention people who are using pam_mysql (and
pam_ldap, along similar lines) via saslauthd. Clearly this isn't really
efficient and only adds a layer for bugs to be found. However that
doesn't mean that PAM as a whole is flawed (though given some of the bug
reports I've seen I certainly feel that way sometimes!). ;)

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper

[Etienne Goyer]

Post by Jeff Wiegley, PhD
I'm sure this has been brought up before. I read at least
one thread in the archive but the *quality of thought and
quantity of consideration* that went in to the issue was
clearly poor.

[... flame snipped ...]

If you want to raise the quality of thought going on this issue, you
should weight your word more carefully. The kind of flame you sent does
not make a healthy debate starter.