Bug 182930 - audit patch doesn't work as expected
audit patch doesn't work as expected
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: openssh (Show other bugs)
4.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
:
: 187491 (view as bug list)
Depends On:
Blocks: 181409
  Show dependency treegraph
 
Reported: 2006-02-24 10:29 EST by Tomas Mraz
Modified: 2007-11-30 17:07 EST (History)
6 users (show)

See Also:
Fixed In Version: RHBA-2006-0303
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-10 17:19:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomas Mraz 2006-02-24 10:29:28 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.
Comment 2 Tomas Mraz 2006-03-02 15:46:33 EST
Steve, is there an easy way how to simulate a resource starvation in audit
subsystem?
Comment 3 Steve Grubb 2006-03-16 12:06:34 EST
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.
Comment 4 Pasi Sjöholm 2006-03-20 14:52:04 EST
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.




Comment 5 Tomas Mraz 2006-03-20 15:31:17 EST
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).
Comment 10 Tomas Mraz 2006-03-31 06:21:53 EST
*** Bug 187491 has been marked as a duplicate of this bug. ***
Comment 11 Roman Kagan 2006-04-04 11:01:16 EDT
(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().
Comment 12 Steve Grubb 2006-04-04 11:09:19 EDT
(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?
Comment 13 Roman Kagan 2006-04-04 13:32:13 EDT
(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?
Comment 14 Steve Grubb 2006-04-04 14:37:18 EDT
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.
Comment 15 David Golden 2006-04-04 16:16:29 EDT
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.


Comment 16 Bob Johnson 2006-04-11 11:50:44 EDT
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.
Comment 21 Nicola Worthington 2006-08-05 19:06:19 EDT
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?
Comment 22 Red Hat Bugzilla 2006-08-10 17:19:55 EDT
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

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