From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f73.google.com (mail-ej1-f73.google.com [209.85.218.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 262EA194AD6 for ; Tue, 1 Oct 2024 07:09:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727766593; cv=none; b=ioK5adm6kW8XWcm05wiGhOPmQrgLVKXWk6WE3BdIGnXsNhwh/poVMKd8dDenI/BDUVqCZSQxRVFMsIZEAspgQ4ZHXRHsdMfCfGxiXfXeQEq45jwAhK5QiP2VxVI16mPA0sjCcfeP+hM9M1G7HPpX1WmGnSH6W7oGj7rEzsNZseY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727766593; c=relaxed/simple; bh=EEfUkg12zVayrkF97+wBeybXQSiAExWRBd2BS7YcViM=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=m85HQQF+RQzPAsbmqL7jKUvnGN5JJZKPTRXc0cuINxCnNbxdDRGtZz238XhPqrAWiNRHZT2MdUtV2UG/uvPSCpk05RdPlouuQoe1BoMHYJv4To/FSxS3YsXghmZJ8EpPsGF3YLO8K6PHrLcVvdd/pAEks69BM4g6N8SAOvwln1Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--gnoack.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=bk2QhsSH; arc=none smtp.client-ip=209.85.218.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--gnoack.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="bk2QhsSH" Received: by mail-ej1-f73.google.com with SMTP id a640c23a62f3a-a8a877c1d22so419878866b.1 for ; Tue, 01 Oct 2024 00:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1727766588; x=1728371388; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=G98NvXM62YT0B0WJqga1aEPWf2fMI/P8gKqX00JsaWE=; b=bk2QhsSH38N4UAxhEtUB72e65ixpvjBwARbkieNPWVAY6MIRTaE/RZxoQ9i+ZXtwkW 6aMioBa3IuCSh1LxCsz+PArTk0iAcBS1Lb4e5r7D183qW+NkvyPhotyQoRwmTjnSc9am QfL5Vubi85A9ze2RM5c9Gec4D13OsOdY80qe8CoTNP1vh4u+XXuX4lIZyH+4Jc9sE9Oj bFZTN5U2TTfYdM+U4VN9iua2GEthNBOKqDs9VXNBoid3dqgQKZtN3dqVhqKhZS8K4Jme oK/zL141fxftRZTomiuF/jq/uUlY/8KHclR/C6LzV3qMtrnfj1uHwOVZRoEMss06R2Es gjOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727766588; x=1728371388; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=G98NvXM62YT0B0WJqga1aEPWf2fMI/P8gKqX00JsaWE=; b=ivht+G8pknyCSvUKoG7NrmZG7k4H0mvZo/vc1xfVWlXBLmo9NjkogKy5vDy1tr/+zd 33g4xksOdP3UmWBkbv3OKliM1Qy3sVLE6V3KUB+1nwNcmBg4n66YVOn9KdYuPpX80pYr vQQh37XfPco3/KS68vNqoq5WEwZMAO4UHs2YNatvzRvAj9wAxylUia5gDpRHZVCZzz7n 0K+aMUAYzdZJtNbTtSwH3/IkYBL+1q3fMuXUHJ+8V2erdPIveGR4qpF5TLq1eo/mgm7g OBsAfvYIkCSVj++3x1MtID94XXqlT2Wt2kg+KwbV60pAMG+vKy1wxxd3kqltPmw2oGh1 6lZg== X-Forwarded-Encrypted: i=1; AJvYcCWVhfq/iouMEBVlZGO9zD/KN9GJfCqgZaFix0jseX9YRJMps32Z/A82JFLD4RYMVxpgcol/7Mw=@vger.kernel.org X-Gm-Message-State: AOJu0Yzy+7OCkzgRMet2JdDpnJGSKv38CFfzXtJ9eY+Ehw12IIMw42au L+sVkvV/B0yTF356CFTHBknkoV/1IywKxRPel9Pu7RjqPiHzdGH9zYhUdLXlhUW3YaMPdKDAvNz K5A== X-Google-Smtp-Source: AGHT+IEFa2kdnyeozPEZpXPOZxvw+akB2zSXUlpMW74Sj1ivjTUlFPXTAwMlPI6ebFhigkPVCITJN5sj1kw= X-Received: from swim.c.googlers.com ([fda3:e722:ac3:cc00:31:98fb:c0a8:1605]) (user=gnoack job=sendgmr) by 2002:a17:906:d214:b0:a8a:7d59:346d with SMTP id a640c23a62f3a-a93c4aab81dmr660266b.10.1727766588055; Tue, 01 Oct 2024 00:09:48 -0700 (PDT) Date: Tue, 1 Oct 2024 09:09:46 +0200 In-Reply-To: <20240904104824.1844082-20-ivanov.mikhail1@huawei-partners.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20240904104824.1844082-1-ivanov.mikhail1@huawei-partners.com> <20240904104824.1844082-20-ivanov.mikhail1@huawei-partners.com> Message-ID: Subject: Re: [RFC PATCH v3 19/19] landlock: Document socket rule type support From: "=?utf-8?Q?G=C3=BCnther?= Noack" To: Mikhail Ivanov Cc: mic@digikod.net, willemdebruijn.kernel@gmail.com, gnoack3000@gmail.com, linux-security-module@vger.kernel.org, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, yusongping@huawei.com, artem.kuzin@huawei.com, konstantin.meskhidze@huawei.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello! On Wed, Sep 04, 2024 at 06:48:24PM +0800, Mikhail Ivanov wrote: > Extend documentation with socket rule type description. > > Signed-off-by: Mikhail Ivanov > --- > Documentation/userspace-api/landlock.rst | 46 ++++++++++++++++++++---- > 1 file changed, 40 insertions(+), 6 deletions(-) >=20 > diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/use= rspace-api/landlock.rst > index 37dafce8038b..4bf45064faa1 100644 > --- a/Documentation/userspace-api/landlock.rst > +++ b/Documentation/userspace-api/landlock.rst > @@ -33,7 +33,7 @@ A Landlock rule describes an action on an object which = the process intends to > perform. A set of rules is aggregated in a ruleset, which can then rest= rict > the thread enforcing it, and its future children. > =20 > -The two existing types of rules are: > +The three existing types of rules are: > =20 > Filesystem rules > For these rules, the object is a file hierarchy, > @@ -44,14 +44,19 @@ Network rules (since ABI v4) > For these rules, the object is a TCP port, > and the related actions are defined with `network access rights`. > =20 > +Socket rules (since ABI v6) > + For these rules, the object is a pair of an address family and a soc= ket type, > + and the related actions are defined with `socket access rights`. > + > Defining and enforcing a security policy > ---------------------------------------- > =20 > We first need to define the ruleset that will contain our rules. > =20 > For this example, the ruleset will contain rules that only allow filesys= tem > -read actions and establish a specific TCP connection. Filesystem write > -actions and other TCP actions will be denied. > +read actions, create TCP sockets and establish a specific TCP connection= . > +Filesystem write actions, creating non-TCP sockets and other TCP > +actions will be denied. > =20 > The ruleset then needs to handle both these kinds of actions. This is > required for backward and forward compatibility (i.e. the kernel and use= r > @@ -81,6 +86,8 @@ to be explicit about the denied-by-default access right= s. > .handled_access_net =3D > LANDLOCK_ACCESS_NET_BIND_TCP | > LANDLOCK_ACCESS_NET_CONNECT_TCP, > + .handled_access_socket =3D > + LANDLOCK_ACCESS_SOCKET_CREATE, > }; > =20 > Because we may not know on which kernel version an application will be > @@ -119,6 +126,11 @@ version, and only use the available subset of access= rights: > case 4: > /* Removes LANDLOCK_ACCESS_FS_IOCTL_DEV for ABI < 5 */ > ruleset_attr.handled_access_fs &=3D ~LANDLOCK_ACCESS_FS_IOCTL_DE= V; > + __attribute__((fallthrough)); > + case 5: > + /* Removes socket support for ABI < 6 */ > + ruleset_attr.handled_access_socket &=3D > + ~LANDLOCK_ACCESS_SOCKET_CREATE; When I patched this in, the indentation of this "case" was off, compared to= the rest of the code example. (The code example uses spaces for indentation, n= ot tabs.) > } > =20 > This enables to create an inclusive ruleset that will contain our rules. > @@ -170,6 +182,20 @@ for the ruleset creation, by filtering access rights= according to the Landlock > ABI version. In this example, this is not required because all of the r= equested > ``allowed_access`` rights are already available in ABI 1. > =20 > +For socket access-control, we can add a rule to allow TCP sockets creati= on. UNIX, > +UDP IP and other protocols will be denied by the ruleset. > + > +.. code-block:: c > + > + struct landlock_net_port_attr tcp_socket =3D { > + .allowed_access =3D LANDLOCK_ACCESS_SOCKET_CREATE, > + .family =3D AF_INET, > + .type =3D SOCK_STREAM, > + }; > + > + err =3D landlock_add_rule(ruleset_fd, LANDLOCK_RULE_SOCKET, > + &tcp_socket, 0); > + IMHO, the length of the "Defining and enforcing a security policy" section = is slowly getting out of hand. This was easier to follow when it was only fil= e system rules. -- I wonder whether we should split this up in subsections fo= r the individual steps to give this a more logical outline, e.g. * Creating a ruleset * Adding rules to the ruleset * Adding a file system rule * Adding a network rule * Adding a socket rule * Enforcing the ruleset > For network access-control, we can add a set of rules that allow to use = a port > number for a specific action: HTTPS connections. > =20 > @@ -186,7 +212,8 @@ number for a specific action: HTTPS connections. > The next step is to restrict the current thread from gaining more privil= eges > (e.g. through a SUID binary). We now have a ruleset with the first rule > allowing read access to ``/usr`` while denying all other handled accesse= s for > -the filesystem, and a second rule allowing HTTPS connections. > +the filesystem, a second rule allowing TCP sockets and a third rule allo= wing > +HTTPS connections. > =20 > .. code-block:: c > =20 > @@ -404,7 +431,7 @@ Access rights > ------------- > =20 > .. kernel-doc:: include/uapi/linux/landlock.h > - :identifiers: fs_access net_access > + :identifiers: fs_access net_access socket_access > =20 > Creating a new ruleset > ---------------------- > @@ -423,7 +450,7 @@ Extending a ruleset > =20 > .. kernel-doc:: include/uapi/linux/landlock.h > :identifiers: landlock_rule_type landlock_path_beneath_attr > - landlock_net_port_attr > + landlock_net_port_attr landlock_socket_attr > =20 > Enforcing a ruleset > ------------------- > @@ -541,6 +568,13 @@ earlier ABI. > Starting with the Landlock ABI version 5, it is possible to restrict the= use of > :manpage:`ioctl(2)` using the new ``LANDLOCK_ACCESS_FS_IOCTL_DEV`` right= . > =20 > +Socket support (ABI < 6) > +------------------------- > + > +Starting with the Landlock ABI version 6, it is now possible to restrict > +creation of user space sockets to only a set of allowed protocols thanks > +to the new ``LANDLOCK_ACCESS_SOCKET_CREATE`` access right. > + > .. _kernel_support: > =20 > Kernel support > --=20 > 2.34.1 >=20 There is a section further below called "Network support" that talks about = the need for CONFIG_INET in order to add a network rule. Do similar restrictio= ns apply to the socket rules as well? Maybe this should be added to the secti= on. Please don't forget -- Tahera Fahimi's "scoped" patches have landed in linux-next by now, so we will need to rebase and bump the ABI version one h= igher than before. Thanks, =E2=80=94G=C3=BCnther