Bug 1270927 - ksu doesn't properly log auth failures
Summary: ksu doesn't properly log auth failures
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: krb5
Version: 7.1
Hardware: All
OS: Linux
low
unspecified
Target Milestone: rc
: ---
Assignee: Robbie Harwood
QA Contact: Filip Dvorak
URL: https://github.com/krb5/krb5/pull/776
Whiteboard:
Depends On: 1575771
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-12 17:12 UTC by Pat Riehecky
Modified: 2020-03-31 19:41 UTC (History)
5 users (show)

Fixed In Version: krb5-1.15.1-45.el7
Doc Type: No Doc Update
Doc Text:
Clone Of:
: 1575771 (view as bug list)
Environment:
Last Closed: 2020-03-31 19:41:21 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:1029 0 None None None 2020-03-31 19:41:40 UTC

Description Pat Riehecky 2015-10-12 17:12:42 UTC
Description of problem:
I'm looking to switch from sudo to .k5users, but the logging is reduced
by comparison.

For example:
sudo: riehecky : TTY=pts/2 ; PWD=/home/riehecky ; USER=root ;
COMMAND=/bin/ls -a
vs
ksu[15242]: pam_unix(ksu:session): session opened for user root by
riehecky(uid=1000)

Can the logging be increased so that the command and its arguments is
logged?

Version-Release number of selected component (if applicable):krb5-1.12.2-15.el7_1


How reproducible:100%


Steps to Reproduce:
1.grant 'someuser' sudo rights to run /bin/ls
2.echo 'someuser /bin/ls' /root/.k5users
3.sudo /bin/ls
4.ksu -e /bin/ls

Actual results:
sudo logs command executed
ksu logs as though the user acquired a full shell

Expected results:
ksu log action performed in a similar manner to sudo

Additional info:
http://krbdev.mit.edu/rt/Ticket/Display.html?id=8270

Comment 4 Robbie Harwood 2018-04-11 21:12:48 UTC
My read of the current state is:

- If the source user is root, no message will be logged.

- If the source user is not root and there's no cmd, a successful or failed auth message is logged.

- If the source user is not root, there's a command, and auth succeds, a message is logged (syslog at NOTICE) which says something like

    "Account TARGET: authorization for CLIENT for execution of CMD successful".

- If the source user is not root, there's a command, and auth fails, a message is logged (syslog at WARNING) which says something like

    "Account TARGET: authorization for CLIENT for execution of CMD failed".

Does that match what you're seeing?  And if so, what part of that (if any) are you requesting improvement in?

Comment 5 Pat Riehecky 2018-04-12 13:19:54 UTC
I'm not seeing the second two (Account TARGET:...) appear in syslog.

$ ksu testuser -e /bin/ls
account testuser: authorization failed

However, I don't show anything logged to secure or messages for execution for non-root target accounts.



I do show a success message for running as root:

$ ksu -e /bin/ls
Authenticated riehecky
Account root: authorization for riehecky for execution of
               /bin/ls successful

==> messages <==
Apr 12 08:18:30 test ksu[396]: Account root: authorization for riehecky for execution of /bin/ls successful

Comment 6 Robbie Harwood 2018-05-07 21:03:38 UTC
I definitely see the non-root success:

may 07 14:50:16 freeipa.rharwood.biz ksu[1769]: 'ksu left' authenticated right for right on /dev/pts/0
may 07 14:50:16 freeipa.rharwood.biz ksu[1769]: Account left: authorization for right for execution of /bin/ls successful

Failures for non-root users (regardless of whether they're running a command, or their target user) don't seem to show up.

Let me see what I can do.

Comment 7 Robbie Harwood 2018-05-31 18:46:27 UTC
Just to double-check - the non-root success and failure logging as described in comment#4 would meet your requirements, right?  And currently the only missing part of that is the failure logging?

Comment 8 Pat Riehecky 2018-05-31 18:49:09 UTC
That is all correct.

Comment 15 errata-xmlrpc 2020-03-31 19:41:21 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1029


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