openssh unix dev - Sep 2021 - Aw: Re: Howto log multiple sftpd instances with their chroot shared via NFS

On 2021/09/22 13:06, Jochen Bern wrote:
> What do the chrooted users have for a homedir *within* the chroot? Would it
> be possible to have /var/data/chroot be a local FS and mount only
> /var/data/chroot/home from the NFS server? (If there are files that you
need
> to keep identical on both servers, e.g., under /var/data/chroot/etc, you
can
> still symlink those to some special subdir like /var/data/chroot/home/ETC
to
> put the actual data onto the NFS share.)
The description was for /var/data/chroot/<username>/dev/log i.e. each
user has their own separate chroot. So this type of approach would
require mounting a local fs of some sort over the top of each user's dir
which soon gets messy.

This is amongst the reasons why OpenBSD has the sendsyslog(2) syscall,
https://man.openbsd.org/sendsyslog.2 - the syslog daemon opens a
kernel socket to receive those messages, and processes which want to
write a log entry just call the standard syslog functions which use
sendsyslog(2) rather than /dev/log, so it works even through FD
exhaustion, in chroot, and with syscall filters that prohibit
filesystem access.

Not entirely pleasant but I suppose it could alternatively be done by
using a LD_PRELOAD wrapper to override syslog functions (I think just
syslog_r is probably enough for openssh) and have them send over a
network socket instead.

On Fri, 24 Sep 2021, Stuart Henderson wrote:
> This is amongst the reasons why OpenBSD has the sendsyslog(2) syscall,
> https://man.openbsd.org/sendsyslog.2 - the syslog daemon opens a
> kernel socket to receive those messages, and processes which want to
> write a log entry just call the standard syslog functions which use
Oh, nice.
> The description was for /var/data/chroot/<username>/dev/log i.e. each
> user has their own separate chroot. So this type of approach would
> require mounting a local fs of some sort over the top of each user's
dir
This made me curious, and I tried? this. It is possible to bind-mount
sockets on Linux iff the target exists as regular file.

sudo touch /var/data/chroot/<username>/dev/log	# but beware of
						# filesystem-based
						# attacks here!
sudo mount --bind /dev/log /var/data/chroot/<username>/dev/log

? I went and began using this technology here:
  https://github.com/mirabilos/shellsnippets/blob/master/posix/debchroot.sh

bye,
//mirabilos
-- 
Infrastrukturexperte ? tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/?\ The UTF-8 Ribbon
? ? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
 ?  HTML eMail! Also,     https://www.tarent.de/newsletter
? ? header encryption!
                        ****************************************************

Thanks, this sounds like the solution could be in this direction.
I think, the sftpd process should just not write to the /dev/log unix socket
(because this leads to the problem here), but to the local kernel directly,
something like what you describe here.

But how could I do this concrete with Ubuntu Linux? What you write is rather
abstract and I am not so expert that I understand what you mean with LD_PRELOAD
wrapper.

Unfortunately, I could not change our sftp server to OpenBSD operating system
since we would not have the capacity to maintain this one special operating
system. We maintain our 350 Ubuntu Linux servers with already established
processes.


> This is amongst the reasons why OpenBSD has the sendsyslog(2) syscall,
> https://man.openbsd.org/sendsyslog.2 - the syslog daemon opens a
> kernel socket to receive those messages, and processes which want to
> write a log entry just call the standard syslog functions which use
> sendsyslog(2) rather than /dev/log, so it works even through FD
> exhaustion, in chroot, and with syscall filters that prohibit
> filesystem access.
>
> Not entirely pleasant but I suppose it could alternatively be done by
> using a LD_PRELOAD wrapper to override syslog functions (I think just
> syslog_r is probably enough for openssh) and have them send over a
> network socket instead.