3 ms·

Perhaps services could have different priorities, and if the wonderful systemd starts a rando user service before the system service, the system service starts

Perhaps services could have different priorities, and if the wonderful systemd starts a rando user service before the system service, the system service starts anyway and the existing user service gets booted off the port.

zibby8 4y ago
What if the port is only opened on demand? Like if system service is in state X, it is listening to port Y, otherwise it is not listening to port Y.
- dinosaurdynasty 4y ago
  Systemd has socket units that could support this, though it requires cooperation from the listening program.
  - nirimda 4y ago
    In case anyone wonders what the cooperation is, normally when you start a program on Linux you get three open file handles: standard input, standard output and standard error. But if you use systemd socket activation, then when your program starts you get an additional open file handle per port. So rather than binding to a port, you ask your webserver library to listen for requests on the extra file handle. De facto, this means the application author needs cooperation from their webserver library - it needs to have been written so that it has the option to listen from an open file handle rather than binding to a port and listening to the file handle it gets as a result of that bind. But since this is a reasonably common usecase, and basically just half of the normal process, you might discover that the library you're already using has support for it. On the other hand, AFAIK docker doesn't support socket activation, so if you use docker to provide your runtime it's game over.
    - dinosaurdynasty 4y ago
      podman supports systemd socket activation, however.
- Brian_K_White 4y ago
  Socket activation means systemd is the listener, and has higher priority. Other forms of activation... idk maybe the same essence. files and dirs and processes are all owned by someone. I don't claim to have thought all angles out, and don't even claim it's a good idea, just a response to a specific point about first-come-first-serve.
throwaway09223 4y ago
Put on your black hat for a moment. You want to pretend to be the sshd on your shared university server and collect passwords or session data from your fellow students foolish enough to ignore host key warnings. 1) You find a way to crash sshd. This might be easier than it seems. Maybe you can fill up a disk partition and cause a fatal logging error, or drive the machine so low on memory that it is killed. If sshd seems too farfetched, pretend you're compromising a less robust system service like the printing subsystem. 2) Try to start your own listener before sshd can be restarted. It's a race, and with enough tries you will eventually win 3) If you're really diabolical, you might notice that there are certain cronjobs or management systems like puppet, chef, ansible, etc that restart system services at known times or after known events (after updating a config file). You write a script to watch for these events (use inotify to event on file updates), and race it to the finish line. There really isn't a good mechanism from userspace for systemd to police ports without race conditions. Privileged ports is a fairly reasonable way to do it.
- fomine3 4y ago
  Also put a black hat: what can be done by theft well-known port is basically like a MiTM attack. Anyway MiTM attack should be prevented by other methods like public key auth.
  - throwaway09223 4y ago
    Creating identities is useful, but also impractical at scale for internal access. Your system depends on non-authenticated privileges. I'll explain: Privileged ports are a permission applied to bind() to a sockaddr of type AF_INET. Privileges are also checked when bind()ing to type AF_UNIX -- aka a unix domain socket -- aka a path to a file in your filesystem. Privileges are also checked when open()ing a local file. It is entirely reasonable to rely on filesystem privileges to control access to regular files like /etc/shadow, or /etc/ssh/ssh_host_ed25519_key. It is entirely reasonable to rely on filesystem privileges to control access to unix domain sockets. It is entirely reasonable to rely on interface privileges to control access to inet sockets. The commonality in all of the above scenarios is that it is reasonable to trust the local system regarding its own access controls. There is no such practical concept as a MiTM between a process and open() to a local file, nor is there such thing as MiTM between a process and a bind() to a local resource. In fact, this local trust is a required component to implement a key based system (note: the need of sshd to trust file permissions to store a host key)

zibby8 4y ago

What if the port is only opened on demand? Like if system service is in state X, it is listening to port Y, otherwise it is not listening to port Y.

dinosaurdynasty 4y ago
Systemd has socket units that could support this, though it requires cooperation from the listening program.
- nirimda 4y ago
  In case anyone wonders what the cooperation is, normally when you start a program on Linux you get three open file handles: standard input, standard output and standard error. But if you use systemd socket activation, then when your program starts you get an additional open file handle per port. So rather than binding to a port, you ask your webserver library to listen for requests on the extra file handle. De facto, this means the application author needs cooperation from their webserver library - it needs to have been written so that it has the option to listen from an open file handle rather than binding to a port and listening to the file handle it gets as a result of that bind. But since this is a reasonably common usecase, and basically just half of the normal process, you might discover that the library you're already using has support for it. On the other hand, AFAIK docker doesn't support socket activation, so if you use docker to provide your runtime it's game over.
  - dinosaurdynasty 4y ago
    podman supports systemd socket activation, however.
Brian_K_White 4y ago
Socket activation means systemd is the listener, and has higher priority. Other forms of activation... idk maybe the same essence. files and dirs and processes are all owned by someone. I don't claim to have thought all angles out, and don't even claim it's a good idea, just a response to a specific point about first-come-first-serve.

throwaway09223 4y ago

Put on your black hat for a moment. You want to pretend to be the sshd on your shared university server and collect passwords or session data from your fellow students foolish enough to ignore host key warnings. 1) You find a way to crash sshd. This might be easier than it seems. Maybe you can fill up a disk partition and cause a fatal logging error, or drive the machine so low on memory that it is killed. If sshd seems too farfetched, pretend you're compromising a less robust system service like the printing subsystem. 2) Try to start your own listener before sshd can be restarted. It's a race, and with enough tries you will eventually win 3) If you're really diabolical, you might notice that there are certain cronjobs or management systems like puppet, chef, ansible, etc that restart system services at known times or after known events (after updating a config file). You write a script to watch for these events (use inotify to event on file updates), and race it to the finish line. There really isn't a good mechanism from userspace for systemd to police ports without race conditions. Privileged ports is a fairly reasonable way to do it.

fomine3 4y ago
Also put a black hat: what can be done by theft well-known port is basically like a MiTM attack. Anyway MiTM attack should be prevented by other methods like public key auth.
- throwaway09223 4y ago
  Creating identities is useful, but also impractical at scale for internal access. Your system depends on non-authenticated privileges. I'll explain: Privileged ports are a permission applied to bind() to a sockaddr of type AF_INET. Privileges are also checked when bind()ing to type AF_UNIX -- aka a unix domain socket -- aka a path to a file in your filesystem. Privileges are also checked when open()ing a local file. It is entirely reasonable to rely on filesystem privileges to control access to regular files like /etc/shadow, or /etc/ssh/ssh_host_ed25519_key. It is entirely reasonable to rely on filesystem privileges to control access to unix domain sockets. It is entirely reasonable to rely on interface privileges to control access to inet sockets. The commonality in all of the above scenarios is that it is reasonable to trust the local system regarding its own access controls. There is no such practical concept as a MiTM between a process and open() to a local file, nor is there such thing as MiTM between a process and a bind() to a local resource. In fact, this local trust is a required component to implement a key based system (note: the need of sshd to trust file permissions to store a host key)