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.
