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.
It might be related to SELinux. Do you see anything related in audit logs? Also anything in /var/log/secure?
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
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
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
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.
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.
*** Bug 842527 has been marked as a duplicate of this bug. ***
Eric, any comments on the patch in comment #6? Or did this get solved by some other commit?
# 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).
Thanks, it works.
This bug is back in F19 (kernel 3.10.2-301).