Bug 906

Summary:

syslog messages from sshd [net] lost

Product:

Portable OpenSSH

Reporter:

Pavel Kankovsky <peak>

Component:

sshd

Assignee:

OpenSSH Bugzilla mailing list <openssh-bugs>

Status:

CLOSED WORKSFORME

Severity:

minor

CC:

t8m

Priority:

Version:

3.8.1p1

Hardware:

All

OS:

Linux

Bug Depends on:

Bug Blocks:

1155

Attachments:

Description	Flags
suppress duplicate log messages	none

Description Pavel Kankovsky 2004-07-23 09:38:46 AEST

sshd [net] is chrooted and cannot access /dev/log. This means syslog() cannot
talk to syslogd and all messages logged by this process are rerouted to the
nearest blackhole. The problem is not apparent at the default LogLevel (in fact
things look better this way at the first glance because superfluous invocations
of auth_log() in the child are suppresed).

Some implementations of syslogd are able to listen on additional sockets but 1.
other implementations lack this feature, 2. one has to mess with syslogd
configuration when sshd is installed.

An alternative approach would be to send log messages to the monitor and let the
monitor forward them to syslogd. I've got a PoC implementation and it appears to
work.

What do you think?

Comment 1 Damien Miller 2004-07-23 09:40:38 AEST

I think it is best to make syslogd listen in /var/empty/dev/log, this is what
OpenBSD does - lots of daemons chroot there, so it makes sense to have a log
socket for all of them.

Comment 2 Pavel Kankovsky 2004-07-23 10:37:48 AEST

dev/log in /var/empty => not empty anymore :)

There are syslogd's out there that cannot listen on multiple sockets...Are
people using those systems (I think you can name any commercial unix) supposed
to replace their standard syslogd? Or run an extra instance of syslogd? (Or
pretend the problem does not exist?)

Comment 3 Damien Miller 2004-07-23 10:53:05 AEST

We won't send log messages to the monitor - that is very, very wrong.

Systems without a syslogd that is able to listen in multiple places can (IMO)
either cope with the loss, fix their syslogd, run a real syslogd (there are
plenty of free ones that support multiple log sockets) or forego privsep.

OTOH the README should mention that /var/empty should have a /dev/log if people
want logging messages from the [net] process.

Comment 4 Darren Tucker 2004-07-23 15:06:48 AEST

Not ideal, but on systems that only support one /dev/log socket you can do this:
# mkdir /var/empty/dev
# mv /dev/log /var/empty/dev/log
# ln -s /var/empty/dev/log /dev/log

Comment 5 Pavel Kankovsky 2004-07-23 18:56:09 AEST

I understand it is against the design goals of privsep to add "unnecessary"
functions, like a syslogd proxy, to the monitor. This is wrong, sure. But, for
the record, what makes it "very, very wrong" (i.e. 2 orders of magnitude worse
than "wrong")? I mean, is there anything besides the violation of design goals?

Comment 6 Damien Miller 2004-07-24 11:54:58 AEST

The point of privsep is to keep this sort of arbitrary untrusted data away from
the privileged process.

Comment 7 Darren Tucker 2006-03-30 23:51:01 AEDT

Created attachment 1104 [details]
suppress duplicate log messages

I just committed this patch, which fixes the double logging and adds some logging on the monitor side for failed authentications.

I know if still misses "postponed" authentications (which may not be worth the effort) but is anything else missing?

Comment 8 Damien Miller 2006-03-31 07:53:28 AEDT

Please note that the intent of Darren's patch is to suppress duplicate logs, not eliminate the need for operating systems to configure their syslogds to listen at /var/log/empty/dev/log (or similar) as the [net] child still logs events of interest.

Comment 9 Damien Miller 2006-07-12 11:25:35 AEST

Closing: we recommend that syslogd listens in /var/empty/dev/log (or equivalent) so all messages from the unprivileged process are captured. 

This is similar to named, postfix and other daemons that operate in a chroot.

Comment 10 Darren Tucker 2006-09-28 19:25:23 AEST

With the release of 4.4, we believe that this bug is now closed.  For information about the release please see http://www.openssh.com/txt/release-4.4 .