6 ms·

IMHO privileged ports are still useful to distinguish ports assigned by system administrator and ports assigned by any user. Otherwise some user service can (in

IMHO privileged ports are still useful to distinguish ports assigned by system administrator and ports assigned by any user. Otherwise some user service can (inadvertently) take some port before a system service that was supposed to use that port started and cause completely preventable failure of the system service. The minor issue with privileges is already solved by CAP_NET_BIND_SERVICE, the init system could just give this capability to every system service, instead of disabling privileged ports system-wide.

Brian_K_White 4y ago
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)
rascul 4y ago
> Otherwise some user service can (inadvertently) take some port before a system service that was supposed to use that port started and cause completely preventable failure of the system service. There are plenty of cases where a web server is just a reverse proxy to :8080 or some other non-privileged port that could potentially be taken over in such a manner.
- XorNot 4y ago
  When you get right down to it the issue is port numbers just plain don't work for this. SELinux had some concept of sending SELinux security contexts over the network so you could get positive claims about what you were talking to, but it was never developed into a full system AFAIK. Which is ultimately what you want: TLS "I'm securely talking to the controller of this domain name" and then a secondary "within that controllers namespace, I'm definitely talking to the service I think I am".
- philsnow 4y ago
  > There are plenty of cases where a web server is just a reverse proxy to :8080 or some other non-privileged port that could potentially be taken over in such a manner True, but you can also proxy through a named unix domain socket on the filesystem and control access to it that way. At least nginx, haproxy, and caddy can all use a unix domain socket as an upstream.
  - rascul 4y ago
    This should generally be preferred when reverse proxying to localhost, as you get to adjust permissions on the socket. Unfortunately people aren't always doing this, and sometimes the upstream app isn't capable.
foota 4y ago
I think the technically correct answer is that you shouldn't be trusting just a port anyway.
- nirimda 4y ago
  If it's SSH or HTTPS you aren't - the SSH client will check the fingerprint and abort on unknown, and the HTTPS client should check the certificate and verify that it was issued when a trusted client could access the same server via the same name. But if you have access to bind to a port, you can trick the trusted HTTP client as much as the end-user client. Maybe SSH is a slightly stronger guarantee here - if port binding permissions are holding out to the extent we haven't disabled them, then file read permissions are probably holding out too.
  - foota 4y ago
    Yeah I would argue if you want security you need to be using something like mutual tls, or a framework/system/etc., that provides the same. That's from the perspective of the developer though, from an end user's perspective I guess you just hope your application is, or that it's something where it doesn't matter.
kalleboo 4y ago
Reserved ports are a good idea, but just blanket "everything under 1024 is for root" is a broken solution, there should be some configuration where you pick individual ports to reserve for specific users - port 80/443 are only for the nginx user, etc
- stjohnswarts 4y ago
  I thought this was possible via firewall rules via iptables?
  - bandie91 4y ago
    it's possible to accept/drop(/reject) traffic from specified port if the listening process owner is this-or-that (see nftables "owner" module), but it can not prevent other users to bind on that port, only prevent them to actually communicate on it.
im3w1l 4y ago
> The minor issue with privileges is already solved by CAP_NET_BIND_SERVICE, the init system could just give this capability to every system service, instead of disabling privileged ports system-wide. This is one of the better suggestions here, but an issue I see is that users are now only able to get ports through the init system. What if some user wants to restart a server they own? Only root can restart a systemd service right?
- kj4ips 4y ago
  > but an issue I see is that users are now only able to get ports through the init system The capabilities can also be specified by a fs attribute using setcap(8). This works like setuid, in the the capability is set whenever the file in question is exec'd. * > Only root can restart a systemd service right By default, only root can manage system-level systemd services, however, you can add policykit rules to allow specific users (or groups) to perform actions on specific services. * Certain sandboxing techniques will break this (like no_new_privs)

Brian_K_White 4y ago

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)

rascul 4y ago

> Otherwise some user service can (inadvertently) take some port before a system service that was supposed to use that port started and cause completely preventable failure of the system service. There are plenty of cases where a web server is just a reverse proxy to :8080 or some other non-privileged port that could potentially be taken over in such a manner.

XorNot 4y ago
When you get right down to it the issue is port numbers just plain don't work for this. SELinux had some concept of sending SELinux security contexts over the network so you could get positive claims about what you were talking to, but it was never developed into a full system AFAIK. Which is ultimately what you want: TLS "I'm securely talking to the controller of this domain name" and then a secondary "within that controllers namespace, I'm definitely talking to the service I think I am".
philsnow 4y ago
> There are plenty of cases where a web server is just a reverse proxy to :8080 or some other non-privileged port that could potentially be taken over in such a manner True, but you can also proxy through a named unix domain socket on the filesystem and control access to it that way. At least nginx, haproxy, and caddy can all use a unix domain socket as an upstream.
- rascul 4y ago
  This should generally be preferred when reverse proxying to localhost, as you get to adjust permissions on the socket. Unfortunately people aren't always doing this, and sometimes the upstream app isn't capable.

foota 4y ago

I think the technically correct answer is that you shouldn't be trusting just a port anyway.

nirimda 4y ago
If it's SSH or HTTPS you aren't - the SSH client will check the fingerprint and abort on unknown, and the HTTPS client should check the certificate and verify that it was issued when a trusted client could access the same server via the same name. But if you have access to bind to a port, you can trick the trusted HTTP client as much as the end-user client. Maybe SSH is a slightly stronger guarantee here - if port binding permissions are holding out to the extent we haven't disabled them, then file read permissions are probably holding out too.
- foota 4y ago
  Yeah I would argue if you want security you need to be using something like mutual tls, or a framework/system/etc., that provides the same. That's from the perspective of the developer though, from an end user's perspective I guess you just hope your application is, or that it's something where it doesn't matter.

kalleboo 4y ago

Reserved ports are a good idea, but just blanket "everything under 1024 is for root" is a broken solution, there should be some configuration where you pick individual ports to reserve for specific users - port 80/443 are only for the nginx user, etc

stjohnswarts 4y ago
I thought this was possible via firewall rules via iptables?
- bandie91 4y ago
  it's possible to accept/drop(/reject) traffic from specified port if the listening process owner is this-or-that (see nftables "owner" module), but it can not prevent other users to bind on that port, only prevent them to actually communicate on it.

im3w1l 4y ago

> The minor issue with privileges is already solved by CAP_NET_BIND_SERVICE, the init system could just give this capability to every system service, instead of disabling privileged ports system-wide. This is one of the better suggestions here, but an issue I see is that users are now only able to get ports through the init system. What if some user wants to restart a server they own? Only root can restart a systemd service right?

kj4ips 4y ago
> but an issue I see is that users are now only able to get ports through the init system The capabilities can also be specified by a fs attribute using setcap(8). This works like setuid, in the the capability is set whenever the file in question is exec'd. * > Only root can restart a systemd service right By default, only root can manage system-level systemd services, however, you can add policykit rules to allow specific users (or groups) to perform actions on specific services. * Certain sandboxing techniques will break this (like no_new_privs)