4

I'm trying to set up a file transfer server, which needs to be secured and logged. FTP was suggested, but that feels outdated so I automatically translated that to SFTP (OpenSSH) in my head.

Using match I can select which users can use the service. Using ChrootDirectory I can select which area of the filesystem to publish. Using ForceCommand I can limit users to file transfer only and set log level.

Now we get to the wonky part. In order for logging to work there must be a syslog socket available in the chroot.

This strikes me as a completely insane design. How can it ever be safe to give a socket directly connected to the logging system to the users I'm trying to track?

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
azzid
  • 143
  • 4

2 Answers2

4

Let's start with what we know:

  • You have a process running in an isolated environment
  • You want that process to communicate with the logging system

It follows therefore that you need to provide some way to route the communication from your process to the logging daemon. There's two ways to do this: Unix sockets or TCP sockets.

To the application, Unix sockets and TCP sockets are roughly identical. In both cases, you connect to the socket and start sending/receiving traffic. But Unix sockets have the security advantage that you can use file permissions to control who can connect to them.

So you're wondering how it could possibly be safe to allow the process to connect to the logging system... but if your process can't see the logging system, then how could you expect it to generate log entries?

To be clear, a unix socket does not give anyone complete control over the process that owns the socket. Instead it allows someone to open up a connection to the process that owns the socket, exactly like using a network connection, but without the network.

tylerl
  • 82,225
  • 25
  • 148
  • 226
2

The linked article is quite outdated and there is possibility to log sftp events even without /dev/log in jailed environment in recent versions of openssh in RHEL (documented in customer portal).

Anyway, it is quite safe if you set up access rights.

How can it ever be safe to give a socket directly connected to the logging system to the users I'm trying to track?

You are not giving the socket away. The user is not interacting with this socket directly, because he doesn't have shell, but the sftp server interact with it.

If you are worried about user removing the socket or something, this is not possible, if you set up access rights in the correct way (as with the log socket in /dev/)

Jakuje
  • 5,229
  • 16
  • 31
  • While the security is my primary concern, there is also a cosmetic issue with having the socket in the chroot. I've searched high and low for someone who has solved this, your comment is the first sign I've seen releasing the socket requirement. If you can find more info I'd be real happy. – azzid Sep 25 '15 at 10:15
  • 1
    Here we wrote up article, but note that this is applicable for RHEL family: https://access.redhat.com/articles/1374633 – Jakuje Sep 25 '15 at 11:02
  • `Red Hat Enterprise Linux Server release 7.1 (Maipo) libssh2-1.4.3-8.el7.x86_64 openssh-6.6.1p1-12.el7_1.x86_64 openssh-clients-6.6.1p1-12.el7_1.x86_64 openssh-server-6.6.1p1-12.el7_1.x86_64` makes the article seem appropriate. I'm grateful. – azzid Sep 25 '15 at 12:19