headers
Wolfgang Draxinger | 2 Aug 2012 17:36
Picon
Favicon

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

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?

Regards,

Wolfgang
Permalink | Reply | 4 comments |
headers
Arpit Tolani | 2 Aug 2012 19:03
Picon

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

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 

_______________________________________________
Pam-list mailing list
Pam-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/pam-list
Permalink | Reply | 1 comment |
headers
Steve Langasek | 2 Aug 2012 21:47
Picon
Favicon

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

On Thu, Aug 02, 2012 at 05:36:55PM +0200, Wolfgang Draxinger wrote:
> 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.

It's so that a regular user can *self* authenticate.  Allowing users to call
this setgid helper directly for other accounts would let them use it for
brute forcing of passwords.  So no, what you're asking for is disallowed by
design.

--

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek <at> ubuntu.com                                     vorlon <at> debian.org

_______________________________________________
Pam-list mailing list
Pam-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/pam-list
Permalink | Reply | 1 comment |
headers
Wolfgang Draxinger | 3 Aug 2012 00:47
Picon
Favicon

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

On Thu, 2 Aug 2012 22:33:13 +0530
Arpit Tolani <arpittolani <at> gmail.com> wrote:

> Why are you using pam authentication for web server?

Well, because regular users on the system shall be able to access
certain private areas of the HTTP tree.

> 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.

In this case the pam service configuration has a rule added that only
users within a certain group are able to use this at all; root is not
in that group of course. So this limits potential dictionary attacks to
said users. Add to this a fail2ban ruleset, that will disallow access
to the server from the originating IP after a number of failed login
attempts.

> * 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!"

That server is TLS only. No plaintext goes over the wire, and caching
is mutually exclusive with TLS (a proxy is a MitM, from a cryptography
point of view).

> 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.

And the benefit of this is? OpenLDAP is a heavyweight beast, and the
password would still go over the wire for basic auth.

> - You can configure LDAP on secure port and all data transfer will be
> done on SSL

Well, would not be very helpful if the server frontend was
still plaintext HTTP.

Wolfgang
Permalink | Reply | 0 comments |
headers
Wolfgang Draxinger | 3 Aug 2012 00:53
Picon
Favicon

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

On Thu, 2 Aug 2012 12:47:36 -0700
Steve Langasek <vorlon <at> debian.org> wrote:

> It's so that a regular user can *self* authenticate.  Allowing users
> to call this setgid helper directly for other accounts would let them
> use it for brute forcing of passwords.  So no, what you're asking for
> is disallowed by design.

Well, how about making brute forcing passwords hard by using a hash
function designed for the use with passwords like bcrypt. That way all
the user did was wasting his CPU cycles without getting close to
anything.

I do understand the motivation for preventing a user to use unix_chkpw
for brute forcing. But what does prevent said user from using `ssh
localhost` for this? Well, the increasing retry delay, maybe a disallow
for localhost (erm...). But one could also add a usleep(100000) after a
negative result, and as such slowing down a brute force significantly.

Wolfgang

_______________________________________________
Pam-list mailing list
Pam-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/pam-list
Permalink | Reply | 0 comments |
headers
Patrick Kile | 27 Aug 2012 23:46
Favicon

Pam_access and netgroups

I'm trying to get restricted ssh login working and running into an issue with pam_access.so and how it interprets netgroups. 

Pam 1.1.3 on Ubuntu 12.04

Netgroup:
UserDev ( ,alloweduser, )
SystemDev (host.sub.domain.com,,)

Here is the /etc/security/access.conf file:
+ : root :ALL
+ : <at> UserDev <at> <at> SystemDev : ALL

Relevant /etc/pam.d/sshd config:
account required pam_access.so debug

And here is what happens when alloweduser logs in via ssh:

login_access: user=alloweduser, from=192.168.1.10, file=/etc/security/access.conf
line 1: +  :  root : ALL
list_match: list= root , item=alloweduser
user_match: tok=root, item=alloweduser
string_match: tok=root, item=alloweduser
user_match=0, "alloweduser"
line 2: +  :   <at> UserDev <at> <at> SystemDev  :  ALL
list_match: list= <at> UserDev <at> <at> SystemDev , item=alloweduser
user_match: tok= <at> UserDev <at> <at> SystemDev, item=alloweduser
netgroup_match: 0 (netgroup=UserDev <at> <at> SystemDev, machine=NULL, user=alloweduser, domain=)
user_match=0, "alloweduser"
line 3: -  :  ALL  :  ALL
list_match: list= ALL , item=alloweduser
user_match: tok=ALL, item=alloweduser
string_match: tok=ALL, item=alloweduser
user_match=2, "alloweduser"
list_match: list= ALL, item=alloweduser
from_match: tok=ALL, item=192.168.1.10
string_match: tok=ALL, item=192.168.1.10
from_match=2, "192.168.1.10"
access denied for user `alloweduser' from `192.168.1.10'

Notice the line: netgroup_match: 0 (netgroup=UserDev <at> <at> SystemDev, machine=NULL, user=alloweduser, domain=)

It isn't correctly interpreting the netgroups as 2 separate groups, but one group named : UserDev <at> <at> SystemDev which obviously fails.

Here is a valid session with the same config on a CentOS 5.5 system.

login_access: user=alloweduser, from=192.168.1.20, file=/etc/security/access.conf
line 1: + : root : ALL
user_match: tok=root, item=alloweduser
string_match: tok=root, item=alloweduser
user_match=0, "alloweduser"
line 2: + : <at> UserDev <at> <at> SystemDev : ALL
user_match: tok= <at> UserDev <at> <at> SystemDev, item=alloweduser
user_match: tok= <at> UserDev, item=alloweduser
netgroup_match: 1 (group=UserDev, machine=NULL, user=alloweduser, domain=NULL)
from_match: tok= <at> SystemDev, item=devsystem2
netgroup_match: 1 (group=SystemDev, machine=devsystem2, user=NULL, domain=NULL)
user_match=1, "alloweduser"
from_match: tok=ALL, item=192.168.1.20
string_match: tok=ALL, item=192.168.1.20
from_match=2, "192.168.1.20"

Any help would be greatly appreciated.
_______________________________________________
Pam-list mailing list
Pam-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/pam-list
Permalink | Reply | 1 comment |
headers
Tomas Mraz | 28 Aug 2012 00:28
Picon
Favicon

Re: Pam_access and netgroups

On Mon, 2012-08-27 at 14:46 -0700, Patrick Kile wrote: 
> I'm trying to get restricted ssh login working and running into an
> issue with pam_access.so and how it interprets netgroups. 
> 
> 
> Pam 1.1.3 on Ubuntu 12.04

This problem was fixed in later Linux-PAM upstream releases.

--

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
Permalink | Reply | 0 comments |

Gmane