PAM Support for Shadow Passwords?

Adam Weiss asks: "So recently while playing around with the Cyrus IMAP server I had a decent opportunity to check out PAM and was pretty impressed. The idea of having an authentication API that applications can use that abstracts the actual mechanism for doing authentication is a really cool idea. However I was quite disappointed when I realized that if your machine is using shadow passwords, the applications requiring authentication services have to run as root. Everybody knows that it's definitely bad security ju-ju to have lots of services and applications running as root; and it's really a buzzkill when the only reason an application has to run as root is because it wants to do authentication against shadowed passwords."

"I know that there are lots of fun hacks for getting around this, some compromising the security of the system more than others. My question is why doesn't PAM provide this functionality? The Apache people strongly recommend against using the system passwd database for web authentication on the grounds that Apache won't do certain things like enforcing security policy like freezing accounts after a certain number of failed login attempts and the like, that the login(1) program provides. It seems to me that it would make a lot of sense if this functionality was moved into PAM, along with support for authenticating against shadow passwd databases for unprivileged programs..."

Re:Stop and Think!

[TBone]

You implement a one-time pad within the PAM 'realm' (for lack of a better term) to encrypt the password. This password is then passed onto the local authentication method for yanking passwords from the shadow file. Yes, it may be broken, but so can SSL, RC4, or any other encryption, given enough time and effort.

Even better, have that PAM module encrypt the auth request within SSL or something itself. No public sniffable traffic any more. The PAM module just had to request the password. What it does behind the scenes (sending it elsewhere, querying files, etc) is up to the implementation. What's the problem with SSL'ing to the host where the shadow passwords are at, connecting to, say, /usr/lib/shadowpamd, and comparind passwords?

Re:Stop and Think!

[TBone]

The man doesn't want to broadcast his passwords across the network, he wants a PAM plugin to to the logical Shadow authentication. You can set up the module, for example, to run one-time pads to encrypt the password so that the part of the PAM that does run as root can get the passwd back, and run it through the salt in /etc/shadow.

Actually, PAM is very cool...it lets you authenticate in umpteen ways from Sunday, and write _one_ method for authentication, letting the PAM libraries sort out the messy details about what's needed for the auth

external DB

[cloudmaster]

One approach touched on by someone else was LDAP. PAM-LDAP (and NSS-LDAP) verifies the password by attempting to bind to the LDAP server as the user. The user has read access to their own info, and no one else's, so after a succesful bind the other user info can be pulled, or if the bind fails, then the password is invalid.

Essentially, there's a trusted app that handles authentication outside of PAM, with a PAM module to use that trusted app. Same idea as the pam_chkpass helper and some of the other similar solutions.

BTW, try to use ssl for networked authentication everywhere, or you're wasting your time with shadow passwords.

Re:PAM is just another library

[MSG]

Know of any place I could look for more information? Like how the server decides what programs are given privileges and how those programs request privileges from the server?

PAM is just another library

[MSG]

The limitation that you're running into is this: you can't SUID a library in UNIX. I understand that you could do this in Multics, but I believe that it was never a feature of UNIX since it's too dangerous. Especially in a threaded application, one could do all kinds of nasty things while the library's running to get unauthorized access. (It might actually work if the library ran as a separate process with its own resources, but I'm going way off topic. Bring this up on a kernel development list and see what kind of responce you get.)

In order for PAM to access any password database, including the shadow file, the application running must be able to access that database. If you don't care about non root users accessing your password database, then you shouldn't be using shadow files. There are other things to consider as well.

Authentication isn't the only reason that a server needs to run as root. A typical login sequence for an interactive daemon works like:
* daemon starts as root
* bind to port (may require root, depending on service)
* accept connection
* read username and password
* compare username and password to authentication db (probably requires root)
* drop root privileges, switching to the authenticated user (definitely requires root)

The last step is an important one. If you want your daemons to be able to switch UID, they have to be run as root. The alternative is to run the imap server as a non-root user with access to the password database, or proxy the username and password to an external authentication daemon, but then all of the mailboxes must be readable and writable by the imap user. It can be done, but then each daemon needs its own hack to get everything working.

Since you can't switch UID's without root, and you can't drop root until after authentication, you're stuck doing authentication as root. You would *think* that this would be a small enough section of code that it wouldn't be commonly exploitable, but it is all the same. </me sighs>

Re:Stop and Think!

[coyote-san]

I've written PAM modules myself, so I know how flexible it is.

But I also know that many sites misuse PAM modules. PAM modules do not, cannot, encrypt traffic "over the wire" and anything sent to the module WILL be sniffed sooner or later. (I've lost track of the number of sites I've seen which use pam_krb5 with Apache, completely ignorant of the numerous ways it violates the Kerberos security model.) Local users (those connecting to Unix sockets) don't have to worry about these issues, but remote users do.

I have absolutely no idea what problem this "one time pad encryption" of the password solves. If the user sends the password in plaintext and the module compares encrypted passwords, a sniffer still captures the password. If the user has to encrypt the password himself, it breaks the PAM design principle that the user interface remains unchanged. (The user may be asked for a password, S/Key password, Kerberos passphrase, SecurID card, etc., but not required to run special programs to access the PAMified application. E.g., a program that encrypts the password with an arbitrary salt.)

PAM *does* support OTP passwords, but they're totally unrelated to the shadow passwords. S/Key passwords, for instance, are an excellent solution to this problem, but overkill for an IMAP account.

Stop and Think!

[coyote-san]

Stop and think about what you're trying to do!

Do you REALLY want to have all of your users send their system login username and password in plaintext across the network?

If so, you might as well make /etc/shadow world-readable because it won't matter. You might as well tell everyone to use 'telnet,' not 'ssh,' for the same reason. Even if you're running inside of a firewall, trust everyone, etc., you still have to be alert to viruses/trojans, visitors leaving a laptop attached to an unused network port, and the like.

Some IMAP clients support SSL authentication/encryption and password sniffing isn't an issue. I don't know if Cyrus is one of them - you'll need to grab the source and look at the documentation.

But if you don't go the SSL route, set up a separate database for your IMAP passwords. Better yet, run the entire process in a "chroot jail" containing *only* the IMAP passwords, so the real passwords are protected even if someone exploits an IMAP vulnerability.

Re:PAM is just another library

[alannon]

It might actually work if the library ran as a separate process with its own resources, but I'm going way off topic. Bring this up on a kernel development list and see what kind of responce you get.

If you take a close look at MacOSX, you might notice that this is how MacOSX manages parts of its security. There is a security server that can give root privileges to programs that require it (such as installers and configuration programs) while running in a separate address space.

Authentication Server

[aridhol]

How 'bout setting up a specific process that is able to authenticate shadow passwords? Your app calls PAM. PAM calls the server. Server says go/no go. Simple right?

Of course, then you have to know...how do I trust the authentication server? Has it been compromised? Is the local socket correct, or has it been rerouted to a hostile app?

I'm not a security expert. Can anybody tell me a problem with this idea?

PAM can easily use shadowed passwords

[Cerlyn]

If you look in the /sbin directory of a system with PAM's pwdb module installed, you'll find a set-uid helper called "pwdb_chkpwd" that is actually used to access the shadow file. The idea is that only simple applications with known code should do password checking. I believe KDE takes a similar approach towards applications that need to do something as root (calling little helper applications to do the tasks needed). And no, you typically can not run this application by hand (it will syslog a complaint if you do).

Note I am not a PAM programmer, so read the documentation to figure out how to use this.

Re:Authentication Server

[helixblue]

Look at SASL (the pwcheck module in particular). This is what Cyrus, and others, use to get around the 'needs root' problem.

Don't need it to run as root

[helixblue]

Here are some workarounds: * Use a backend database. LDAP is of course preferred, SQL and NIS work as well too. You'll have to set NIS into insecure mode to accept non root-port queries however. * Give the account access to the shadow database. For instance, you can give cyrus read access to /etc/shadow. If you've got a security paranoid OS (*BSD), you will have to make a single line patch to libc so it doesn't ignore it, as it has a specific root check. Of course, on the above security paranoid OS's, every time you use a tool that modifies the passwd database, your permissions get reset.