Red Hat Bugzilla – Bug 182930
audit patch doesn't work as expected
Last modified: 2007-11-30 17:07:23 EST
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
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
I'm running RHEL4 with vanilla-220.127.116.11 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
*** 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 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
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 18.104.22.168
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.