Syslog socket missing from chroot.

Bug #582443 reported by Mike Mestnik
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
openssh (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

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

Revision history for this message
Mike Mestnik (cheako) wrote :
Revision history for this message
Christopher Hotchkiss (christopher-hotchkiss) wrote :

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.

Changed in openssh (Ubuntu):
status: New → Incomplete
Revision history for this message
Colin Watson (cjwatson) wrote :

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.

Changed in openssh (Ubuntu):
importance: Undecided → Medium
status: Incomplete → Triaged
Revision history for this message
Colin Watson (cjwatson) wrote :

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

Revision history for this message
Mike Mestnik (cheako) wrote :

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.

Revision history for this message
Mike Mestnik (cheako) wrote :

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?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.