Bug 816567 - pam_tty_audit is broken
pam_tty_audit is broken
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Eric Paris
Fedora Extras Quality Assurance
:
: 842527 (view as bug list)
Depends On:
Blocks: 841909
  Show dependency treegraph
 
Reported: 2012-04-26 08:32 EDT by Roman Rakus
Modified: 2014-01-12 19:14 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 841909 (view as bug list)
Environment:
Last Closed: 2012-10-25 08:01:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Work-in progress patch (7.08 KB, patch)
2012-05-09 10:55 EDT, Miloslav Trmač
no flags Details | Diff

  None (edit)
Description Roman Rakus 2012-04-26 08:32:38 EDT
Description of problem:
I'm playing with pam_tty_audit. Added
session   required pam_tty_audit.so disable=* enable=root
from example part of man page to /etc/pam.d/system-auth
And now I can't login as root. I'm not sure if tty is audited.


Version-Release number of selected component (if applicable):
pam-1.1.5-5.fc16.x86_64


How reproducible:
100%


Steps to Reproduce:
1. add session   required pam_tty_audit.so disable=* enable=root to /etc/pam.d/system-auth
2. try to log in as root
3.
  
Actual results:
$ su -
Password: 
su: cannot not open session: Cannot make/remove an entry for the specified session


Expected results:
success login


Additional info:
I'm going to reboot, remove pam_tty_audit.so and look if tty is audited.
Comment 1 Tomas Mraz 2012-04-26 08:42:14 EDT
It might be related to SELinux. Do you see anything related in audit logs?
Also anything in /var/log/secure?
Comment 2 Miloslav Trmač 2012-04-26 09:09:49 EDT
Current guess: kernel's net/netlink/af_netlink.c:netlink_autobind set's the socket's "pid" to something that is not a PID, and kernel/audit.c:audit_receive_msg uses the socket's "pid" to look up the sending task (which is always "current", so the lookup is not necessary with current netlink semantics).  I still need to verify this.

I can't see anything in audit logs.  /var/log/secure has
> Apr 26 14:21:48 kulicka login: pam_unix(login:session): session opened for user root by LOGIN(uid=0)
> Apr 26 14:21:48 kulicka login: pam_tty_audit(login:session): error reading current audit status: No such process
> Apr 26 14:21:48 kulicka login: Cannot make/remove an entry for the specified session
Comment 3 David Ford 2012-04-26 14:45:34 EDT
i think it's something more specific to tty audit.  i have a 3.3.3 kernel on my system, no SELinux. notably, the auditd package works fine and is logging events normally.

i patched af_netlink.c to indicate what pid is chosen:

[...]
    printk(KERN_ERR "netlink: my pid for netlink_autobind() %i\n", pid);

retry:
    cond_resched();
    netlink_table_grab();
    head = nl_pid_hashfn(hash, pid);
    sk_for_each(osk, node, head) {
        if (!net_eq(sock_net(osk), net))
            continue;
        if (nlk_sk(osk)->pid == pid) {
            /* Bind collision, search negative pid values. */
            pid = rover--;
            printk(KERN_ERR "netlink: bind collision, searching negative pid values: %i\n", pid);
            if (rover > -4097)
                rover = -4097;
            netlink_table_ungrab();
            goto retry;
        }
    }
    netlink_table_ungrab();

    printk(KERN_ERR "netlink: chose pid: %i\n", pid);
    ppid = pid;

    err = netlink_insert(sk, net, pid);
    if (err == -EADDRINUSE)
        goto retry;

    if (pid != ppid)
        printk(KERN_ERR "netlink: chose alternet pid: %i\n", pid);




This is the dmesg since the start of my attempted ssh:

[  751.033551] netlink: my pid for netlink_autobind() 4724
[  751.033554] netlink: chose pid: 4724
[  774.582854] netlink: my pid for netlink_autobind() 4728
[  774.582857] netlink: chose pid: 4728
[  774.583282] netlink: my pid for netlink_autobind() 4728
[  774.583284] netlink: chose pid: 4728
[  774.584378] netlink: my pid for netlink_autobind() 4728
[  774.584380] netlink: chose pid: 4728
[  774.584735] netlink: my pid for netlink_autobind() 4728
[  774.584737] netlink: bind collision, searching negative pid values: -4099
[  774.584739] netlink: chose pid: -4099
[  774.584827] netlink: my pid for netlink_autobind() 4728
[  774.584829] netlink: bind collision, searching negative pid values: -4100
[  774.584831] netlink: chose pid: -4100
[  778.622529] netlink: my pid for netlink_autobind() 4724
[  778.622532] netlink: chose pid: 4724
[  778.634031] netlink: my pid for netlink_autobind() 4724
[  778.634033] netlink: chose pid: 4724
[  778.645664] netlink: my pid for netlink_autobind() 4724
[  778.645666] netlink: chose pid: 4724
[  778.646384] netlink: my pid for netlink_autobind() 4724
[  778.646387] netlink: chose pid: 4724
[  778.804569] netlink: my pid for netlink_autobind() 4724
[  778.804571] netlink: chose pid: 4724
[  778.804789] netlink: my pid for netlink_autobind() 4724
[  778.804791] netlink: chose pid: 4724
[  778.806558] netlink: my pid for netlink_autobind() 4724
[  778.806561] netlink: chose pid: 4724
[  778.806646] netlink: my pid for netlink_autobind() 4724
[  778.806648] netlink: chose pid: 4724
[  778.828427] netlink: my pid for netlink_autobind() 4724
[  778.828429] netlink: chose pid: 4724
[  778.828582] netlink: my pid for netlink_autobind() 4724
[  778.828584] netlink: bind collision, searching negative pid values: -4101
[  778.828586] netlink: chose pid: -4101
[  778.829310] netlink: my pid for netlink_autobind() 4724
[  778.829313] netlink: chose pid: 4724
[  778.829450] netlink: my pid for netlink_autobind() 4724
[  778.829452] netlink: bind collision, searching negative pid values: -4102
[  778.829454] netlink: chose pid: -4102
[  778.831228] netlink: my pid for netlink_autobind() 4732
[  778.831230] netlink: chose pid: 4732
[  778.831554] netlink: my pid for netlink_autobind() 4732
[  778.831557] netlink: chose pid: 4732
[  778.911524] netlink: my pid for netlink_autobind() 4724
[  778.911527] netlink: chose pid: 4724
[  778.911724] netlink: my pid for netlink_autobind() 4724
[  778.911727] netlink: bind collision, searching negative pid values: -4103
[  778.911730] netlink: chose pid: -4103
Comment 4 David Ford 2012-04-27 02:01:15 EDT
correct pid information is obtained by patching kernel/audit.c:677

- pid  = NETLINK_CREDS(skb)->pid;
+ pid  = NETLINK_CB(skb).pid;

this is in reference to git commit 16e5726269611b71c930054ffe9b858c1cea88eb

however, although TTY auditing is now enabled, no TTY records are being collected
Comment 5 Miloslav Trmač 2012-05-02 06:26:36 EDT
Thanks.  Looking at some other recent-ish changes to audit.c, the most direct approach is probably to use "current" directly instead of the netlink socket attributes - I'll look at this more next week.

> however, although TTY auditing is now enabled, no TTY records are being
> collected
If you aren't testing a process with explicit USER_TTY support running as root, make sure that the audited process has exited before looking at the logs.
Comment 6 Miloslav Trmač 2012-05-09 10:55:55 EDT
Created attachment 583319 [details]
Work-in progress patch

The attached patch fixes TTY auditing and incorrect UIDs and PIDs for me.

I'm, however, really unsure how PID/UID namespaces are supposed to work, and rather than me spending several days studying this, it would probably be better if somebody who knows how these things work could help and make sure that it is done correctly.

Eric, could you take a look at this patch, review and push it upstream, please?

The patch notes are copy&pasted below.


Commit 16e5726269611b71c930054ffe9b858c1cea88eb changed
AF_UNIX to not send credentials by default, also affecting AF_NETLINK:
NETLINK_CREDS().uid and pid are zero unless the calling application explictily
sends credentials.

This boroke existing user-space applications (all invocations of auditctl
are logged as pid=0, uid=0; AUDIT_TTY_[GS]ET can not find the invoking process
because it is looing for PID 0).

Actually, using NETLINK_CREDS is not necessary because the netlink requests
are always handled within the sending process, so we can just use "current" and
simplify the code.

Commit fd778461524849afd035679030ae8e8873c72b81 started moving in this
direction, this patch finishes the move.

---

I think I got the locking and the decision to use euid and not ruid (like
SCM_CREDENTIALS do) right, but careful review would be appreciated.

I'm really unsure about handling of PID/UID namespaces - AFAICS the old code
used to use PIDs and UIDs in the calling process namespace, but they went
into the system-wide audit log, so it seems to me that they should use a
system-wide namespace instead.  I'm not at all certain sure that I'm using the
PID/UID namespace API correctly, either.
Comment 7 Tomas Mraz 2012-07-26 06:14:32 EDT
*** Bug 842527 has been marked as a duplicate of this bug. ***
Comment 8 Josh Boyer 2012-09-06 10:20:15 EDT
Eric, any comments on the patch in comment #6?  Or did this get solved by some other commit?
Comment 9 Dave Jones 2012-10-23 11:30:28 EDT
# Mass update to all open bugs.

Kernel 3.6.2-1.fc16 has just been pushed to updates.
This update is a significant rebase from the previous version.

Please retest with this kernel, and let us know if your problem has been fixed.

In the event that you have upgraded to a newer release and the bug you reported
is still present, please change the version field to the newest release you have
encountered the issue with.  Before doing so, please ensure you are testing the
latest kernel update in that release and attach any new and relevant information
you may have gathered.

If you are not the original bug reporter and you still experience this bug,
please file a new report, as it is possible that you may be seeing a
different problem. 
(Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).
Comment 10 Roman Rakus 2012-10-25 03:50:04 EDT
Thanks, it works.
Comment 11 Gabriel VLASIU 2013-07-25 03:08:24 EDT
This bug is back in F19 (kernel 3.10.2-301).

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