openssh bugs - Jul 2004 - [Bug 906] syslog messages from sshd [net] lost

http://bugzilla.mindrot.org/show_bug.cgi?id=906

           Summary: syslog messages from sshd [net] lost
           Product: Portable OpenSSH
           Version: 3.8.1p1
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: minor
          Priority: P2
         Component: sshd
        AssignedTo: openssh-bugs at mindrot.org
        ReportedBy: peak at argo.troja.mff.cuni.cz


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?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=906





------- Additional Comments From djm at mindrot.org  2004-07-23 09:40 -------
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.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=906





------- Additional Comments From peak at argo.troja.mff.cuni.cz  2004-07-23
10:37 -------
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?)





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=906





------- Additional Comments From djm at mindrot.org  2004-07-23 10:53 -------
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.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=906





------- Additional Comments From dtucker at zip.com.au  2004-07-23 15:06 -------
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



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=906





------- Additional Comments From peak at argo.troja.mff.cuni.cz  2004-07-23
18:56 -------
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?




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=906





------- Additional Comments From djm at mindrot.org  2004-07-24 11:54 -------
The point of privsep is to keep this sort of arbitrary untrusted data away from
the privileged process.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.