TCP listen control

[l0kod]

LANDLOCK_ACCESS_NET_BIND_TCP is useful to limit the scope of "bindable" ports to forbid a malicious sandboxed process to impersonate a legitimate server process. However, bind(2) might be used by (TCP) clients to set the source port to a (legitimate) value. This use case is an issue because we cannot allow a whole range of ports (e.g., >= 1024).

A LANDLOCK_ACCESS_NET_LISTEN_TCP would make more sense to control incoming connections to a specific port.

Being able to restrict listen(2) may lead to a cover channel where the sandboxed process can infer some properties (e.g. port) from the socket file descriptior (e.g. if it was passed from another process). This doesn't seem to be a security issue though.

Controlling accept(2) might not be worth it because:

• performance impact (i.e. evaluated for each new client connection);
• it would make more sense to be able to control access according to the client address/port but
• sandboxing is to protect the outside of the sandbox from the inside.

See thread: https://lore.kernel.org/all/b4440d19-93b9-e234-007b-4fc4f987550b@digikod.net/

Related to #6

Cc @BoardzMaster

v1: https://lore.kernel.org/all/20240728002602.3198398-1-ivanov.mikhail1@huawei-partners.com/
v0: https://lore.kernel.org/all/20240408094747.1761850-1-ivanov.mikhail1@huawei-partners.com/

[sm1ling-knight]

The problem is that (TCP) client is unable to use ports that are restricted for server, right?

[l0kod]

The problem is that (TCP) client is unable to use ports that are restricted for server, right?

Yes, a client would not be allowed to bind to a specific port (for a newly initiated outgoing connection) if its domain handles LANDLOCK_ACCESS_NET_BIND_TCP but no rule explicitly allows binding on this port. This should not be an issue for most use cases, but some systems fine tune their TCP connections.

[sm1ling-knight]

The problem is that (TCP) client is unable to use ports that are restricted for server, right?

Yes, a client would not be allowed to bind to a specific port (for a newly initiated outgoing connection) if its domain handles LANDLOCK_ACCESS_NET_BIND_TCP but no rule explicitly allows binding on this port. This should not be an issue for most use cases, but some systems fine tune their TCP connections.

For example, a use case where some kind of server process forks the client and the client 's available ports are limited due to the parent ruleset, right?

[l0kod]

For example, a use case where some kind of server process forks the client and the client 's available ports are limited due to the parent ruleset, right?

If a new process is spawned per client connection, then the new process doesn't need any specific right to reply on the opened socket/file descriptor. Indeed, in this case, there is no call to connect(2) nor bind(2), only send/write and recv/read.

A use case where a client process does an explicit bind(2) and then a connect(2) on the same socket can happen on high-volume networks because the kernel may take too much time to find an available port. In this case a specific algorithm can be used by user space to efficiently deal with port allocation. This should probably not be used on a public network for security reasons though.

Another use case is to use a specific network interface or IP address.

[sm1ling-knight]

A use case where a client process does an explicit bind(2) and then a connect(2) on the same socket can happen on high-volume networks because the kernel may take too much time to find an available port. In this case a specific algorithm can be used by user space to efficiently deal with port allocation. This should probably not be used on a public network for security reasons though.

But why in this case client's domain might need to handle LANDLOCK_ACCESS_NET_BIND_TCP?

[l0kod]

A use case where a client process does an explicit bind(2) and then a connect(2) on the same socket can happen on high-volume networks because the kernel may take too much time to find an available port. In this case a specific algorithm can be used by user space to efficiently deal with port allocation. This should probably not be used on a public network for security reasons though.

But why in this case client's domain might need to handle LANDLOCK_ACCESS_NET_BIND_TCP?

They shouldn't unless we can specify a port range (#16). What would make more sense is to use LANDLOCK_ACCESS_NET_LISTEN_TCP instead.

[l0kod]

@BoardzMaster, do you still want to work on this or should we let this open for others?

[BoardzMaster]

Hi @l0kod. @sm1ling-knight he is my colleague and he works on this now. I will give him a hand.