public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
From: "Günther Noack" <gnoack@google.com>
To: Alejandro Colomar <alx@kernel.org>
Cc: linux-man@vger.kernel.org, linux-security-module@vger.kernel.org,
	"Günther Noack" <gnoack@google.com>,
	"Mickaël Salaün" <mic@digikod.net>,
	"Tahera Fahimi" <fahimitahera@gmail.com>,
	"Tanya Agarwal" <tanyaagarwal25699@gmail.com>
Subject: [PATCH man 3/3] landlock.7: Update wording in line with kernel side proposal
Date: Fri, 24 Jan 2025 16:37:10 +0000	[thread overview]
Message-ID: <20250124163709.168805-4-gnoack@google.com> (raw)
In-Reply-To: <20250124154445.162841-1-gnoack@google.com>

Cc: Mickaël Salaün <mic@digikod.net>
Cc: Tahera Fahimi <fahimitahera@gmail.com>
Cc: Tanya Agarwal <tanyaagarwal25699@gmail.com>
Link: https://lore.kernel.org/linux-security-module/20250124154445.162841-2-gnoack@google.com/
Signed-off-by: Günther Noack <gnoack@google.com>
---
 man/man7/landlock.7 | 75 ++++++++++++++++++++++-----------------------
 1 file changed, 37 insertions(+), 38 deletions(-)

diff --git a/man/man7/landlock.7 b/man/man7/landlock.7
index 30dbac73d..749b4a3fa 100644
--- a/man/man7/landlock.7
+++ b/man/man7/landlock.7
@@ -357,46 +357,45 @@ which means the tracee must be in a sub-domain of the tracer.
 Similar to the implicit
 .BR "Ptrace restrictions" ,
 we may want to further restrict interactions between sandboxes.
-Each Landlock domain can be explicitly scoped for a set of actions
-by specifying it on a ruleset.
-For example, if a sandboxed process should not be able to
-.BR connect (2)
-to a non-sandboxed process through abstract
+Therefore, at ruleset creation time,
+each Landlock domain can restrict the scope for certain operations,
+so that these operations can only reach out to processes
+within the same Landlock domain or in a nested Landlock domain (the "scope").
+.P
+The operations which can be scoped are:
+.P
+.TP
+.B LANDLOCK_SCOPE_SIGNAL
+When set,
+this limits the sending of signals to target processes
+which run within the same or a nested Landlock domain.
+.TP
+.B LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET
+When set, this limits the set of abstract
 .BR unix (7)
-sockets,
-we can specify such a restriction with
-.BR LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET .
-Moreover, if a sandboxed process should not be able
-to send a signal to a non-sandboxed process,
-we can specify this restriction with
-.BR LANDLOCK_SCOPE_SIGNAL .
-.P
-A sandboxed process can connect to a non-sandboxed process
-when its domain is not scoped.
-If a process's domain is scoped,
-it can only connect to sockets created by processes in the same scope.
-Moreover,
-If a process is scoped to send signal to a non-scoped process,
-it can only send signals to processes in the same scope.
-.P
-A connected datagram socket behaves like a stream socket
-when its domain is scoped,
-meaning if the domain is scoped after the socket is connected,
-it can still
+sockets we can
+.BR connect (2)
+to
+to socket addresses which were created
+by a process in the same or a nested Landlock domain.
+.IP
+A
+.BR send (2)
+on a non-connected datagram socket is treated like an implicit
+.BR connect (2)
+and will be blocked when the remote end does not stem
+from the same or a nested Landlock domain.
+.IP
+A
 .BR send (2)
-data just like a stream socket.
-However, in the same scenario,
-a non-connected datagram socket cannot send data (with
-.BR sendto (2))
-outside its scope.
-.P
-A process with a scoped domain can inherit a socket
-created by a non-scoped process.
-The process cannot connect to this socket since it has a scoped domain.
-.P
-IPC scoping does not support exceptions, so if a domain is scoped,
-no rules can be added to allow access to resources or processes
-outside of the scope.
+on a socket which was previously connected will work.
+This works for both datagram and stream sockets.
+.P
+IPC scoping does not support exceptions via
+.BR landlock_add_rule (2).
+If an operation is scoped within a domain,
+no rules can be added to allow access
+to resources or processes outside of the scope.
 .\"
 .SS Truncating files
 The operations covered by
-- 
2.48.1.262.g85cc9f2d1e-goog


  parent reply	other threads:[~2025-01-24 16:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20250124154445.162841-1-gnoack@google.com>
     [not found] ` <20250124154445.162841-2-gnoack@google.com>
2025-01-24 15:59   ` [PATCH 2/2] landlock: Clarify IPC scoping documentation Günther Noack
2025-02-02 12:51     ` Alejandro Colomar
2025-02-26 20:52       ` Günther Noack
2025-02-26 21:21         ` Alejandro Colomar
2025-02-11 15:20     ` Mickaël Salaün
2025-01-24 16:37 ` [PATCH man 1/3] landlock.7: Update description of Landlock rules Günther Noack
2025-01-24 16:37 ` [PATCH man 2/3] landlock.7: Move over documentation for ABI version 6 Günther Noack
2025-01-24 16:37 ` Günther Noack [this message]
2025-02-11 15:17 ` [PATCH 1/2] landlock: Minor typo and grammar fixes in IPC scoping documentation Mickaël Salaün
2025-02-11 15:27   ` Alejandro Colomar
2025-02-11 15:53     ` Mickaël Salaün
2025-02-11 16:13       ` Alejandro Colomar
2025-02-11 18:08         ` G. Branden Robinson
2025-02-12 15:15           ` Alejandro Colomar
2025-02-11 19:24         ` Mickaël Salaün
2025-02-12 15:06           ` Alejandro Colomar
2025-02-26 20:24             ` Günther Noack
2025-02-26 20:57               ` Alejandro Colomar
2025-02-26 21:38                 ` Günther Noack
2025-02-26 21:51                   ` Alejandro Colomar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250124163709.168805-4-gnoack@google.com \
    --to=gnoack@google.com \
    --cc=alx@kernel.org \
    --cc=fahimitahera@gmail.com \
    --cc=linux-man@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    --cc=tanyaagarwal25699@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox