On Wed, Jun 28, 2023 at 12:03 PM Mickaël Salaün <mic@xxxxxxxxxxx> wrote: > > > 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). > Agree also. > > >> 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? > I agree this field is not commonly used, so might not be that useful. In most cases, the protocol field will just be 0. One case I thought of previously is building an icmp or DHCP packet with raw socket, but now I'm not sure what kind of support/enforce the kernel has for the protocol field with raw socket. We can drop this for now, if there is a clearer requirement in future, it is easy to add a new rule. > > > > >> 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
