Giters

reactphp / socket

Async, streaming plaintext TCP/IP and secure TLS socket server and client connections for ReactPHP.

Home Page:https://reactphp.org/socket/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Is it possible / good practice to start a socket and the drop privileges

jason69 opened this issue · comments

commented

Hi,

In a tls context, private keys generally belong to root.

I wonder if I can:

  1. build my socket as root
  2. start listening
  3. drop privileges (posix_setuid() ?)
  4. run the loop

This would also allow listening on privileged ports (80 or 443).

What do you think about this? Would it effectively work?

Or should I simply give access right to the private key to non-root users?

commented

NB: I did some preliminary tests and it seems it doesn't work.
Dropping privileges after listen do work, but the server will fail during TLS handshake.
However I am allowed to listen on a privileged port and drop privileges after...

commented

About listening to privileged port, #164 should provide a better solution

commented

It won't work, because certificates / keys are currently read from disk for every handshake.

commented

@jason69 Very good question! I'll answer this in two parts:

I wonder if I can:

  1. build my socket as root

  2. start listening

  3. drop privileges (posix_setuid() ?)

  4. run the loop

This would also allow listening on privileged ports (80 or 443).

What do you think about this? Would it effectively work?

Absolutely! This is a very common approach when listening on privileged ports (a.k.a. "well known" ports in the range 1-1023).

Some other alternatives would be using a dedicated socket server like systemd, assigning the CAP_NET_BIND_SERVICE capability or using firewall rules to route your traffic to an unprivileged port. Likewise, if you're using HTTP, it's very common to simply run this in a reverse-proxy setup behind nginx/HAProxy etc. and then forward to your unprivileged port.

If your use case is HTTP, I would highly recommend running this behind a reverse proxy instead. This not only solves this problem, but also brings a host of additional features like request validation, logging, HTTP/2 support and much more.

In a tls context, private keys generally belong to root. […]

Or should I simply give access right to the private key to non-root users?

I would say this is a very reasonable approach. IMO private keys should be owned by specific system users and should only have read access for this specific user. This helps reducing possible attack surface and also helps ensuring a higher level of isolation between different processes.

I believe this has been answered, so I'm closing this for now. Please come back with more details if this problem persists and we can reopen this 👍