[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fbb03199-a953-90f0-451d-bce90b25c7fb@huawei.com>
Date: Tue, 26 Apr 2022 13:17:11 +0300
From: Konstantin Meskhidze <konstantin.meskhidze@...wei.com>
To: Mickaël Salaün <mic@...ikod.net>
CC: <willemdebruijn.kernel@...il.com>,
<linux-security-module@...r.kernel.org>, <netdev@...r.kernel.org>,
<netfilter-devel@...r.kernel.org>, <yusongping@...wei.com>,
<artem.kuzin@...wei.com>, <anton.sirazetdinov@...wei.com>
Subject: Re: [RFC PATCH v4 07/15] landlock: user space API network support
4/12/2022 7:10 PM, Mickaël Salaün пишет:
>
> On 12/04/2022 16:05, Konstantin Meskhidze wrote:
>>
>>
>> 4/12/2022 4:48 PM, Mickaël Salaün пишет:
>>>
>>> On 12/04/2022 13:21, Mickaël Salaün wrote:
>>>>
>>>> On 09/03/2022 14:44, Konstantin Meskhidze wrote:
>>>
>>> [...]
>>>
>>>>> @@ -184,7 +185,7 @@ SYSCALL_DEFINE3(landlock_create_ruleset,
>>>>>
>>>>> /* Checks content (and 32-bits cast). */
>>>>> if ((ruleset_attr.handled_access_fs |
>>>>> LANDLOCK_MASK_ACCESS_FS) !=
>>>>> - LANDLOCK_MASK_ACCESS_FS)
>>>>> + LANDLOCK_MASK_ACCESS_FS)
>>>>
>>>> Don't add cosmetic changes. FYI, I'm relying on the way Vim does
>>>> line cuts, which is mostly tabs. Please try to do the same.
>>>
>>> Well, let's make it simple and avoid tacit rules. I'll update most of
>>> the existing Landlock code and tests to be formatted with
>>> clang-format (-i *.[ch]), and I'll update the landlock-wip branch so
>>> that you can base your next patch series on it. There should be some
>>> exceptions that need customization but we'll see that in the next
>>> series. Anyway, don't worry too much, just make sure you don't have
>>> style-only changes in your patches.
>>
>> I have already rebased my next patch series on your landlock-wip
>> branch. So I will wait for your changes meanwhile refactoring my v5
>> patch series according your comments.
>
> Good.
>
>>
>> Also I want to discuss adding demo in sandboxer.c to show how landlock
>> supports network sandboxing:
>>
>> - Add additional args like "LL_NET_BIND=port1:...:portN"
>> - Add additional args like "LL_NET_CONNECT=port1:...:portN"
>> - execv 2 bash procceses:
>> 1. first bash listens in loop - $ nc -l -k -p <port1> -v
>> 2. second bash to connects the first one - $ nc <ip> <port>
>>
>> What do you think? its possible to present this demo in the next v5
>> patch series.
>
> This looks good! I think LL_TCP_BIND and LL_TCP_CONNECT would fit better
> though.
> Got it. Thanks
> I'm not sure if I already said that, but please remove the "RFC " part
> for the next series.
Ok.
> .
Powered by blists - more mailing lists