pam_unix.so and unix_chkpw setgid - does it work for regular users?

[Arpit Tolani]

Hello

On Thu, Aug 2, 2012 at 9:06 PM, Wolfgang Draxinger <
Wolfgang.Draxinger at physik.uni-muenchen.de> wrote:

> Hi,
>
> I'm currently trying to configure user authentication on a webserver,
> that shall use the normal system user names and passwords. I'm using
> Nginx as webserver, together with the auth_pam module, as packages by
> Debian wheezy.
>
> I expected that since unix_chkpw is set setgid shadow I could use
> pam_unix.so for the webserver service just as is. However it turned
> out, that the user for the webserver process must be in the group
> "shadow" for authentication to work. If the webserver can't read shadow
> it doesn't work.
>
> I was under the impression the idea of unix_chkpw was to have process
> separation and by having a thoroughly audited helper program, that can
> be setgid safely so that a regular user can perform pam_unix.so tests.
>
> Did I miss something here?
>
>
>


Why are you using pam authentication for web server ?Using PAM
authentication with apache/ngnix is a very bad idea. Here are some
reasons :

* The Web technology provides no governors on how often or how rapidly
password (authentication failure) retries can be made. That means that
someone can hammer away at your system's root password using the Web,
using a dictionary or similar mass attack, just as fast as the wire
and your server can handle the requests. Most operating systems these
days include attack detection (such as n failed passwords for the same
account within m seconds) and evasion (breaking the connection,
disabling the account under attack, disabling all logins from that
source, et cetera), but the Web does not.

* An account under attack isn't notified (unless the server is heavily
modified); there's no "You have 19483 login failures" message when the
legitimate owner logs in.

* Without an exhaustive and error-prone examination of the server
logs, you can't tell whether an account has been compromised.
Detecting that an attack has occurred, or is in progress, is fairly
obvious, though - if you look at the logs.

* Web authentication passwords (at least for Basic authentication)
generally fly across the wire, and through intermediate proxy systems,
in what amounts to plain text. "O'er the net we go/Caching all the
way;/O what fun it is to surf/Giving my password away!"

* Since HTTP is stateless, information about the authentication is
transmitted each and every time a request is made to the server.
Essentially, the client caches it after the first successful access,
and transmits it without asking for all subsequent requests to the
same server.

* It's relatively trivial for someone on your system to put up a page
that will steal the cached password from a client's cache without them
knowing. Can you say "password grabber"?

Refer http://httpd.apache.org/docs/1.3/misc/FAQ.html#passwdauth

A possible solution for you will be to Add all your users in LDAP and
use LDAP auth instead. Benefits of using LDAP auth are

- All apache servers can access LDAP server & create a centralized
authentication setup.
- You can configure LDAP on secure port and all data transfer will be
done on SSL

Regards
Arpit Tolani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pam-list/attachments/20120802/057b0ce7/attachment.htm>