Dear Linux, Privileged Ports Must Die

Re:Dear Linux, Privileged Ports Must Die by fomine3 on Wednesday August 31, 2022 @09:53PM (#32670890)

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.

[ Parent | on HN ]

Re:Dear Linux, Privileged Ports Must Die by throwaway09223 on Wednesday August 31, 2022 @10:07PM (#32670995)

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)

[ Parent | on HN ]

Re:Dear Linux, Privileged Ports Must Die by zajio1am on Wednesday August 31, 2022 @10:20PM (#32671095)

Even if the other methods prevented MiTM attack, it is still DoS attack (as the expected service is not available).

[ Parent | on HN ]

Re:Dear Linux, Privileged Ports Must Die by stouset on Wednesday August 31, 2022 @10:21PM (#32671103)

You can enforce public-key auth server-side, but you can't enforce that your clients won't prompt for a password if the (attacker-run) sshd a client connects to requires it.

Clients should be configured correctly to never ask. But many won't be and that's out of your control.

[ Parent | on HN ]