On 28/06/2023 04:33, Jeff Xu wrote:
On Mon, Jun 26, 2023 at 8:29 AM Mickaël Salaün <mic@xxxxxxxxxxx> wrote:
Reviving Günther's suggestion to deny a set of network protocols:
On 14/03/2023 14:28, Mickaël Salaün wrote:
On 13/03/2023 18:16, Konstantin Meskhidze (A) wrote:
2/24/2023 1:17 AM, Günther Noack пишет:
[...]
* Given the list of obscure network protocols listed in the socket(2)
man page, I find it slightly weird to have rules for the use of TCP,
but to leave less prominent protocols unrestricted.
For example, a process with an enabled Landlock network ruleset may
connect only to certain TCP ports, but at the same time it can
happily use Bluetooth/CAN bus/DECnet/IPX or other protocols?
We also have started a discussion about UDP protocol, but it's
more complicated since UDP sockets does not establish connections
between each other. There is a performance problem on the first place here.
I'm not familiar with Bluetooth/CAN bus/DECnet/IPX but let's discuss it.
Any ideas here?
All these protocols should be handled one way or another someday. ;)
I'm mentioning these more obscure protocols, because I doubt that
Landlock will grow more sophisticated support for them anytime soon,
so maybe the best option would be to just make it possible to
disable these? Is that also part of the plan?
(I think there would be a lot of value in restricting network
access, even when it's done very broadly. There are many programs
that don't need network at all, and among those that do need
network, most only require IP networking.
Indeed, protocols that nobody care to make Landlock supports them will
probably not have fine-grained control. We could extend the ruleset
attributes to disable the use (i.e. not only the creation of new related
sockets/resources) of network protocol families, in a way that would
make sandboxes simulate a kernel without such protocol support. In this
case, this should be an allowed list of protocols, and everything not in
that list should be denied. This approach could be used for other kernel
features (unrelated to network).
Btw, the argument for more broad disabling of network access was
already made at https://cr.yp.to/unix/disablenetwork.html in the
past.)
This is interesting but scoped to a single use case. As specified at the
beginning of this linked page, there must be exceptions, not only with
AF_UNIX but also for (the newer) AF_VSOCK, and probably future ones.
This is why I don't think a binary approach is a good one for Linux.
Users should be able to specify what they need, and block the rest.
Here is a design to be able to only allow a set of network protocols and
deny everything else. This would be complementary to Konstantin's patch
series which addresses fine-grained access control.
First, I want to remind that Landlock follows an allowed list approach
with a set of (growing) supported actions (for compatibility reasons),
which is kind of an allow-list-on-a-deny-list. But with this proposal,
we want to be able to deny everything, which means: supported, not
supported, known and unknown protocols.
I think this makes sense. ChomeOS can use it at the process level:
disable network, allow VSOCK only, allow TCP only, etc.
We could add a new "handled_access_socket" field to the landlock_ruleset
struct, which could contain a LANDLOCK_ACCESS_SOCKET_CREATE flag.
If this field is set, users could add a new type of rules:
struct landlock_socket_attr {
__u64 allowed_access;
int domain; // see socket(2)
I guess "family" would also make sense. It's the name used in the
kernel, the "AF" prefixes, and address_families(7). I'm not sure why
"domain" was chosen for socket(2).
int type; // see socket(2)
}
Do you want to add "int protocol" ? which is the third parameter of socket(2)
According to protocols(5), the protocols are defined in:
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
It is part of IPv4/IPV6 header:
https://www.rfc-editor.org/rfc/rfc791.html#section-3.1
https://www.rfc-editor.org/rfc/rfc8200.html#section-3
I understand the rationale but I'm not sure if this would be useful. Do
you have use cases?
The allowed_access field would only contain
LANDLOCK_ACCESS_SOCKET_CREATE at first, but it could grow with other
actions (which cannot be handled with seccomp):
- use: walk through all opened FDs and mark them as allowed or denied
- receive: hook on received FDs
- send: hook on sent FDs
also bind, connect, accept.
I don't think "accept" would be useful, and I'm not sure if "bind" and
"connect" would not be redundant with LANDLOCK_ACCESS_NET_{CONNECT,BIND}_TCP
Bind and connect for a datagram socket is optional, so this might lead
to a false sense of security. If we want to support protocols other than
TCP to restrict bind/connect, then they deserve to be controlled
according to a port (or similar).
We might also use the same approach for non-socket objects that can be
identified with some meaningful properties.
What do you think?
-Jeff
