Syslog socket missing from chroot.

[Mike Mestnik]

Hello,
  sshd attempts to open /var/run/sshd/dev/log in order to log events, but this file did not exist.

I ran "mkdir /var/run/sshd/dev" and added "$AddUnixListenSocket /var/run/sshd/dev/log" to "/etc/rsyslog.d/75-ssh.conf". That should fix things up.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: openssh-server 1:5.3p1-3ubuntu3
ProcVersionSignature: Ubuntu 2.6.32-22.33-generic-pae 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic-pae i686
Architecture: i386
Date: Tue May 18 13:44:27 2010
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100427.1)
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
SSHDConfig:
 Error: command ['gksu', '-D', 'Apport', '--', '/usr/sbin/sshd', '-T'] failed with exit code 1: GNOME_SUDO_PASSSorry, try again.
 sudo: 3 incorrect password attempts
SourcePackage: openssh

[Christopher Hotchkiss (christopher-hotchkiss)]

Mike,
Could you please post your sshd config file so we can work on reproducing the bug? (It should be /etc/ssh/sshd_config). I'm going to mark it as Incomplete for the meantime.

[Colin Watson (cjwatson)]

This is trivially reproducible without the need for configuration files. We should not be wasting bug reporters' time asking them for unnecessary information ...

This is a long-standing problem, but I would rather not give the unprivileged network monitor direct access to syslog. Instead, any logging it does should be directed through the privsep protocol. Not trivial work.

[Colin Watson (cjwatson)]

(Though I'm prepared to change my mind on this; I should probably look into how it's done on e.g. OpenBSD.)

[Mike Mestnik (cheako)]

My strace revealed that sshd was indeed attempting to open this socket and failing. I can see where if a user can inject into sshd that injecting into rsyslog would be trial for this person.

I don't fully understand the ramifications of extra code lying around to do things like:
1. Test for the existence of this socket.
   a. Act on config option enabling/disabling this.
2. Test for the existence of a /var/log folder or /var/log/auth.log file.
   a. Act on config option enabling/disabling this.

Though the current code might not have anything wrong with it, AFAIK. If by default this file should not exist then there should be a config option set to disable it's use, with instructions on enabling syslog for testing.

Perhaps this should be something only done in testing and should be disable by default.

If one wanted a filtering proxy to be vary strict about the messages passed through this socket, then perhaps the solution is for sshd to provide such a proxy. This way messages could be limited to only the messages sshd itself would generate.

[Mike Mestnik (cheako)]

I've discovered that a chroot can be escaped by chrooting to any file. I'm interested on how this plays on attempting to protect /dev/log? From what I can gather is that chroots should not be used as a security measure(as they are in this case), but only as a device to run multiple distributions at the same time.

Am I wrong?