Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1686442 - [RFE]Add syslog message when user logs in with blank password when debug option is used with pam_unix
Summary: [RFE]Add syslog message when user logs in with blank password when debug opti...
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: pam
Version: 8.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 8.0
Assignee: Tomas Mraz
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-07 13:29 UTC by amitkuma
Modified: 2019-04-09 10:38 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-07 13:50:19 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

Description amitkuma 2019-03-07 13:29:11 UTC
Description of problem:

1. Removed 'x' for user 'test2' from /etc/passwd, but password string is not removed from /etc/shadow.
# cat /etc/passwd|grep test2
test2::1001:1001::/home/test2:/bin/bash

# cat /etc/shadow|grep test2
test2:$6$cELtwRPK$s7OZEKzuI3KRE5fh5iaBi1lEwUVqKC5TqDXVc0qqDpyEeAW1dHLNUhEhHc5NUg7GXVI9nm7Qs/E7k7e6q/tqQ0:17962:0:99999:7:::

2. configured pam_unix debugging using rsyslog.

3. Tried logging to user 'test2'.

4. No information regarding 'test2' does not have 'x' entry inside /etc/passwd is logged.
 -> Now if customer by mistake removed 'x' from /etc/passwd. Then there is no way to know why 'test2' is logging without password... It requires heavy research going into pam.d configuration to find why 'test2' is behaving as root.


$ cat /etc/pam.d/system-auth-ac |grep pam_unix
auth        sufficient    pam_unix.so nullok try_first_pass debug
account     required      pam_unix.so debug
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok  debug
session     required      pam_unix.so debug

# vim /etc/rsyslog.d/debugging.conf
*.debug /var/log/debug.log
# service rsyslog restart

# su - test1
# su - test2

# tail -f /var/log/debug.log
Mar  7 07:45:23 rhel7u6-1 su: pam_succeed_if(su-l:session): requirement "service in crond" not met by user "root"
Mar  7 07:45:23 rhel7u6-1 su: pam_unix(su-l:session): session closed for user test1
Mar  7 07:45:54 rhel7u6-1 polkitd[2706]: Registered Authentication Agent for unix-process:12328:8967177 (system bus name :1.734 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Mar  7 07:45:54 rhel7u6-1 systemd: Stopping System Logging Service...
Mar  7 07:45:54 rhel7u6-1 rsyslogd: [origin software="rsyslogd" swVersion="8.24.0-34.el7" x-pid="12267" x-info="http://www.rsyslog.com"] exiting on signal 15.
Mar  7 07:45:54 rhel7u6-1 systemd: Stopped System Logging Service.
Mar  7 07:45:54 rhel7u6-1 systemd: Starting System Logging Service...
Mar  7 07:45:54 rhel7u6-1 rsyslogd: [origin software="rsyslogd" swVersion="8.24.0-34.el7" x-pid="12345" x-info="http://www.rsyslog.com"] start
Mar  7 07:45:54 rhel7u6-1 systemd: Started System Logging Service.
Mar  7 07:45:54 rhel7u6-1 polkitd[2706]: Unregistered Authentication Agent for unix-process:12328:8967177 (system bus name :1.734, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Mar  7 07:46:00 rhel7u6-1 su: (to test1) root on pts/0
Mar  7 07:46:00 rhel7u6-1 su: pam_succeed_if(su-l:session): requirement "service in crond" not met by user "root"
Mar  7 07:46:00 rhel7u6-1 su: pam_unix(su-l:session): session opened for user test1 by root(uid=0)
Mar  7 07:46:01 rhel7u6-1 su: (to test2) root on pts/0
Mar  7 07:46:01 rhel7u6-1 su: pam_succeed_if(su-l:session): requirement "service in crond" not met by user "test1"
Mar  7 07:46:01 rhel7u6-1 su: pam_unix(su-l:session): session opened for user test2 by root(uid=1000)


Version-Release number of selected component (if applicable):


How reproducible:
# rpm -qa|grep pam
pam-1.1.8-22.el7.x86_64


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:
- pam should log some information that why 'test2' is behaving as root.


Additional info:
pam_localuser.so logs some information from where we can check there is not 'x' in /etc/passwd entry

$ cat /etc/pam.d/system-auth|grep localuser
account     sufficient    pam_localuser.so debug
# service rsyslog restart

==> /var/log/secure <==
............
Mar  7 07:25:04 rhel7u6-1 su: pam_localuser(su-l:account): checking "test1:x:1000:1000::/home/test1:/bin/bash#012"
Mar  7 07:25:04 rhel7u6-1 su: pam_localuser(su-l:account): checking "test2::1001:1001::/home/test2:/bin/bash#012" <<<<<<<<<<<<<<<

Comment 2 Tomas Mraz 2019-03-07 13:49:57 UTC
Removal of x from /etc/passwd is simply indication that the given user does not use /etc/shadow anymore. Do not do that if that is the intention. This is one of the most basic things about unix account system and it is definitely not a role of PAM to educate sys admins about such stuff.

Comment 5 Daniele Palumbo 2019-03-07 14:31:37 UTC
Hi,

pam_unix behave as the code say, but the debug messages are not printed in syslog.

https://github.com/linux-pam/linux-pam/blob/master/modules/pam_unix/pam_unix_auth.c#L149 
> D(("user '%s' has blank passwd", name)); 

D is defined of course in pam package 
https://github.com/linux-pam/linux-pam/blob/master/libpam/include/security/_pam_macros.h#L149 
"""
#define D(x) do { \
    _pam_output_debug_info(__FILE__, __FUNCTION__, __LINE__); \
    _pam_output_debug x ; \
} while (0)
"""

test ~ # grep -re debug /etc/rsyslog.conf /etc/rsyslog.d/*
/etc/rsyslog.d/05-debug.conf:*.debug      /var/log/debug.log
test ~ # 

test ~ # grep pam_unix /etc/pam.d/system-auth
auth        sufficient  pam_unix.so nullok try_first_pass debug
account     required      pam_unix.so nullok try_first_pass broken_shadow no_pass_expiry
password    sufficient    pam_unix.so remember=23 sha512 shadow nullok use_authtok
session     sufficient    pam_unix.so
test ~ #

"""
[1]+ tail -f /var/log/debug.log &amp;
test ~ # logger auth.debug test
test ~ # Feb 26 17:37:58 test user: auth.debug test
test ~ # su - user
Feb 26 17:38:04 test su: (to user) user on pts/1
Feb 26 17:38:04 test su: pam_unix(su-l:session): session opened for user user by user(uid=0)
[<a href="mailto:user@test">user@test</a> ~]$ su -
Feb 26 17:38:07 test su: pam_localuser(su-l:auth): checking "root::0:0:root:/root:/bin/bash#012"
Feb 26 17:38:07 test su: pam_unix(su-l:account): unrecognized option [no_pass_expiry]
Feb 26 17:38:07 test su: (to root) user on pts/1
Feb 26 17:38:07 test su: pam_unix(su-l:session): session opened for user root by user(uid=1002382)
test ~ # logout
Feb 26 17:38:13 test su: pam_unix(su-l:session): session closed for user root
[<a href="mailto:user@test">user@test</a> ~]$ logout
Feb 26 17:38:14 test su: pam_unix(su-l:session): session closed for user user
test ~ #
"""

Thanks,
Daniele

Comment 6 Tomas Mraz 2019-03-07 14:34:28 UTC
The debug messages are not built in. The debug messages availability is a build time option and we do not want these to be built in for production code.

Comment 7 Daniele Palumbo 2019-03-07 23:04:02 UTC
Despite the fact that I personally think that debug logs can be useful, 
I think that "we do not want these to be built in for production" has to be analyzed.

reasons:
- usage of debug is listed in https://access.redhat.com/articles/1314883 for pam_unix as well as the man page (in example) and no info that this is not available.
- if i write "debug" in pam_unix, i am aware of what i am doing (or anyway man page can refer it).


For the specific issue, my feeling is also that
"user '%s' has blank passwd"
is not a debug message, but info level.

Comment 8 Tomas Mraz 2019-03-08 09:01:50 UTC
No, the debug option enables different messages than those from D() macro in the code.

We can talk about moving some particular message D() to debug option logging or even to info message as a RFE, but due to the constraints on RFEs on RHEL-7 it should be reported against RHEL-8.

Comment 9 amitkuma 2019-03-12 13:04:37 UTC
||The debug messages are not built in. The debug messages availability is a build time option and we do not want these to be built in for production code.
- Then what is the way if someone want pam to be debugged, Since, customers cannot 'make; make install' pam packages for watching the debug messages.

||Yes I feel better option is to move (Some Messages + Info Messages)
We can talk about moving some particular message D() to debug option logging or even to info message as a RFE.

||but due to the constraints on RFEs on RHEL-7 it should be reported against RHEL-8.
-> Ok, Let us take Customer's opinion on this?

Reopening the bugzilla.

Comment 10 amitkuma 2019-03-30 08:36:19 UTC
Hello,
Customer is looking to add following into debug messages.
=======Created By: Daniele Palumbo  (3/22/2019 7:18 PM)==========
Please understand that here we would like to have more debug generally, so if Eng can do a quick review over D() current macro, i think this would be the best.

Also tomas told that he agree on moving "some" messages (not all for sure, but open to do "not only that one")

Our candidates:
https://github.com/linux-pam/linux-pam/blob/master/modules/pam_unix/pam_unix_auth.c#L133
https://github.com/linux-pam/linux-pam/blob/master/modules/pam_unix/pam_unix_auth.c#L135
https://github.com/linux-pam/linux-pam/blob/master/modules/pam_unix/pam_unix_auth.c#L162

This has been done pretty much quickly, so feel free to counter/add/remove messages.
The most important remain for sure:
https://github.com/linux-pam/linux-pam/blob/master/modules/pam_unix/pam_unix_auth.c#L149
===========================================================================

Comment 11 Tomas Mraz 2019-04-01 08:48:05 UTC
The debug message from line 162 does not seem to me to be a good candidate for conversion as this is something that does not really indicate anything that has any significance on production machines. Otherwise, I am OK with converting these to debug syslog messages which would be issued with the debug option.

Comment 12 amitkuma 2019-04-01 08:59:14 UTC
Dear tomas.
I feel you are correct.

Rather we can modify the Log something as, or something similar!
D(("No User cached Authentication token found!"));
inplace of
D(("conversation function is not ready yet"));

I have conveyed your thoughts to Customer, Waiting for his response.

Comment 13 Tomas Mraz 2019-04-01 09:22:03 UTC
No, there should not be production debug message in this case at all. I am not talking about the text.

Comment 14 amitkuma 2019-04-09 10:38:32 UTC
Dear tomas,
Customer is fine to have this message in debug:
D(("No User cached Authentication token found!"));


Note You need to log in before you can comment on or make changes to this bug.