Description of problem: If audit subsystem fails and returns error the patch incorrectly assumes that returning 0 from login_write() function will abort the connection. But it doesn't and that means only subsequent execution of the function is prevented -> no entry written in /var/log/wtmp. This is completely wrong. The return 0 should be replaced with fatal() call.
Steve, is there an easy way how to simulate a resource starvation in audit subsystem?
There's not an easy way. Most likely cause is that they are doing their own kernel or short of kernel memory. You might play with backlog size, "auditctl -b 10" or something like that. Otherwise, we'd have to build a kernel guaranteed to fail.
I'm running RHEL4 with vanilla-2.6.12.5 kernel and noticed that openssh audit-patch breaks writing to /var/run/utmp and /var/log/wtmp at logon time. I have also enabled CONFIG_AUDIT and CONFIG_AUDITSYSCALL for the kernel. Now I can login with ssh without leaving a trace about my login if auditd isn't running. Nice security-feature... audit-patch should not do this kind of stuff if someone wants to run vanilla-kernel.
This is exactly the reason why this bug report was opened. However note that this doesn't affect users with audit support compiled in kernel (official RHEL-4 supported kernels).
*** Bug 187491 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > Description of problem: > If audit subsystem fails and returns error the patch incorrectly assumes that > returning 0 from login_write() function will abort the connection. But it > doesn't and that means only subsequent execution of the function is prevented -> > no entry written in /var/log/wtmp. This is completely wrong. The return 0 should > be replaced with fatal() call. I blatantly disagree. A failure to write an audit record shouldn't impact the system operation. Especially if audit subsytem was disabled on purpose, like when you build a kernel with CONFIG_AUDIT=no. Imagine that you stop, say, syslogd and out of the sudden you can't log on to your machine any more. Rather, the check of linux_audit_write_entry() return value and the following 'return 0' should be thrown away, just like for all other *_write_entry() calls in login_write().
(In reply to comment #11) Failure to write an audit record has to impact the system according to Common Criteria Protection Profiles. There are certain errnos that are returned when the kernel doesn't support auditing. We can use that to ignore errors for those people. But, also note that this bug is about RHEL4 which has the audit support compiled in. Are you recompiling the RHEL4 kernel?
(In reply to comment #12) > Failure to write an audit record has to impact the system according to Common > Criteria Protection Profiles. I don't know which profiles you're trying to adhere to, but it's weird that this 'security' feature in ssh can't be turned off. Besides, with the unreliable communication method like netlink you can never be sure that you've managed to _write_ an audit record; you can only send it, and be certain someone was listening. E.g. it's perfectly possible to run RHEL kernel with audit=0, or turn audit off with auditctl; the kernel would still listen on the socket but drop on the floor everything that comes in. I don't see how it is different security-wise from running a CONFIG_AUDIT=no kernel. > There are certain errnos that are returned when > the kernel doesn't support auditing. Certain errnos? Is there anything but ECONNREFUSED at message submission time? > We can use that to ignore errors for those > people. That would be nice. However, I'm still failing to see why audit has to be compiled in sshd at all. Isn't audit support in PAM enough? > But, also note that this bug is about RHEL4 which has the audit support > compiled in. Are you recompiling the RHEL4 kernel? No, I'm running non-RedHat kernels. Doesn't sound like a valid reason for RHEL4 ssh to misbehave, does it?
Well, we agree that there is a flaw in the implementation and are fixing it. But yes, there is a difference between compiling a kernel with no support and turning audit off at runtime. The difference is that netlink still works. The errnos that you get can be one of any of these depending on what was turned off: EINVAL, EPROTONOSUPPORT, EAFNOSUPPORT. In any event, we are in the process of fixing it and this bugzilla only covers RHEL4. There was a separate bz for FC.
A note re non-redhat kernels: The "new user space message types" such as AUDIT_USER_LOGIN don't appear until vanilla kernel 2.6.13 or so, though were included in RHEL4 kernel 2.6.9-34 (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175415 ) Vanilla audit 1.0.12 has some code in to attempt fall back to AUDIT_USER (an old message type) if AUDIT_USER_LOGIN (one of the new message types) is rejected by kernel. However the RHEL4 audit 1.0.12 srpm in turn includes "audit-1.0.3-old-kernels-are-wimps.patch" which eliminates the fallback attempt citing deadlock avoidance. This likely explains the why of Pasi Sjöholm's problem: vanilla 2.6.12.5 exhibiting the issue even with audit support compiled in.
This issue is on Red Hat Engineering's list of planned work items for the upcoming Red Hat Enterprise Linux 4.4 release. Engineering resources have been assigned and barring unforeseen circumstances, Red Hat intends to include this item in the 4.4 release.
I'm experiencing a problem on 4 new rhel4es boxes where logins over ssh with UseLogin set to no, no longer show users logged in through w and who (stracing the ssh process shows that it's opening the utmp file in rw mode but doesn't appear to write to it). Screen sessions however do show up in w and who. All machines are vanilla kernel and nothing out of the ordinary. We don't see the problem on other older rhel4es boxes we have. Can I just get clarificatin that this is related or the same thing as described in this bug?
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0303.html