On 03/07/2023 11:04, Konstantin Meskhidze (A) wrote:
6/23/2023 5:35 PM, Jeff Xu пишет:
On Thu, Jun 22, 2023 at 9:50 AM Mickaël Salaün <mic@xxxxxxxxxxx> wrote:
On 13/06/2023 22:12, Mickaël Salaün wrote:
On 13/06/2023 12:13, Konstantin Meskhidze (A) wrote:
6/7/2023 8:46 AM, Jeff Xu пишет:
On Tue, Jun 6, 2023 at 7:09 AM Günther Noack <gnoack@xxxxxxxxxx> wrote:
On Tue, May 16, 2023 at 12:13:39AM +0800, Konstantin Meskhidze wrote:
Describe network access rules for TCP sockets. Add network access
example in the tutorial. Add kernel configuration support for network.
Signed-off-by: Konstantin Meskhidze <konstantin.meskhidze@xxxxxxxxxx>
[...]
@@ -28,20 +28,24 @@ appropriately <kernel_support>`.
Landlock rules
==============
-A Landlock rule describes an action on an object. An object is currently a
-file hierarchy, and the related filesystem actions are defined with `access
-rights`_. A set of rules is aggregated in a ruleset, which can then restrict
-the thread enforcing it, and its future children.
+A Landlock rule describes an action on a kernel object. Filesystem
+objects can be defined with a file hierarchy. Since the fourth ABI
+version, TCP ports enable to identify inbound or outbound connections.
+Actions on these kernel objects are defined according to `access
+rights`_. A set of rules is aggregated in a ruleset, which
+can then restrict the thread enforcing it, and its future children.
I feel that this paragraph is a bit long-winded to read when the
additional networking aspect is added on top as well. Maybe it would
be clearer if we spelled it out in a more structured way, splitting up
the filesystem/networking aspects?
Suggestion:
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 restrict the thread enforcing it, and its future
children.
The two existing types of rules are:
Filesystem rules
For these rules, the object is a file hierarchy,
and the related filesystem actions are defined with
`filesystem access rights`.
Network rules (since ABI v4)
For these rules, the object is currently a TCP port,
Remote port or local port ?
Both ports - remote or local.
Hmm, at first I didn't think it was worth talking about remote or local,
but I now think it could be less confusing to specify a bit:
"For these rules, the object is the socket identified with a TCP (bind
or connect) port according to the related `network access rights`."
A port is not a kernel object per see, so I tried to tweak a bit the
sentence. I'm not sure such detail (object vs. data) would not confuse
users. Any thought?
Well, here is a more accurate and generic definition (using "scope"):
A Landlock rule describes a set of actions intended by a task on a scope
of objects. A set of rules is aggregated in a ruleset, which can then
restrict the thread enforcing it, and its future children.
The two existing types of rules are:
Filesystem rules
For these rules, the scope of objects is a file hierarchy,
and the related filesystem actions are defined with
`filesystem access rights`.
Network rules (since ABI v4)
For these rules, the scope of objects is the sockets identified
with a TCP (bind or connect) port according to the related
`network access rights`.
What do you think?
I found this is clearer to me (mention of bind/connect port).
In networking, "5-tuple" is a well-known term for connection, which is
src/dest ip, src/dest port, protocol. That is why I asked about
src/dest port. It seems that we only support src/dest port at this
moment, right ?
Another feature we could consider is restricting a process to "no
network access, allow out-going , allow incoming", this might overlap
with seccomp, but I think it is convenient to have it in Landlock.
Adding protocol restriction is a low hanging fruit also, for example,
a process might be restricted to UDP only (for RTP packet), and
another process for TCP (for signaling) , etc.
Hi,
By the way, UPD protocol brings more performance challenges here
beacuse it does not establish a connection so every UDP packet will be
hooked by Landlock to check apllied rules.
Correct, but I think that for performant-sensitive applications, it
would not be an issue to check sendto and recvfrom for UDP because they
should use connect/bind and send/recv instead, and we can check
connect/bind without checking send/recv. Indeed, bind and connect can be
used to configure an UDP socket, even if it is not a connected protocol
this enables to limit the number of kernel checks and copies. I'm not
sure how many applications use sendto and recvfrom though.
For thread dedicated to UDP, see
https://lore.kernel.org/r/77be3dcf-cae1-f754-ac2a-f9eeab063d76@xxxxxxxxxx
