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
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
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
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/48675413/Dependencies.txt
--
Syslog socket missing from chroot.
https://bugs.launchpad.net/bugs/582443
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in
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
--
Syslog socket missing from chroot.
