All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: <linux-security-module@vger.kernel.org>, <netdev@vger.kernel.org>,
	<netfilter@vger.kernel.org>, <yusongping@huawei.com>,
	<artem.kuzin@huawei.com>
Subject: Re: [RFC PATCH 2/2] landlock: selftests for bind and connect hooks
Date: Tue, 8 Feb 2022 06:01:34 +0300	[thread overview]
Message-ID: <9a77fc40-4463-4344-34d0-184d427d32cf@huawei.com> (raw)
In-Reply-To: <ae0fcafa-3e8d-d6f2-26a8-ae74dda8371c@digikod.net>



2/7/2022 3:49 PM, Mickaël Salaün пишет:
> 
> On 07/02/2022 08:11, Konstantin Meskhidze wrote:
>>
>>
>> 2/1/2022 9:31 PM, Mickaël Salaün пишет:
>>>
>>> On 24/01/2022 09:02, Konstantin Meskhidze wrote:
>>>> Support 4 tests for bind and connect networks actions:
>>>
>>> Good to see such tests!
>>>
>>>
>>>> 1. bind() a socket with no landlock restrictions.
>>>> 2. bind() sockets with landllock restrictions.
> 
> [...]
> 
>>>> + */
>>>> +
>>>> +#define _GNU_SOURCE
>>>> +#include <errno.h>
>>>> +#include <fcntl.h>
>>>> +#include <linux/landlock.h>
>>>> +#include <string.h>
>>>> +#include <sys/prctl.h>
>>>> +#include <sys/socket.h>
>>>> +#include <sys/types.h>
>>>> +#include <netinet/in.h>
>>>> +#include <arpa/inet.h>
>>>
>>> To make it determinisitic (and ease patching/diff/merging), you 
>>> should sort all the included files (in tests and in the kernel code).
>>
>>    Sorry. Did not get your point here. Could you explain in a bit more
>>    details please.
> 
> It will be easier to sort all the #include lines with the "sort -u" 
> command.

   Ok. I got it. Thanks.
> 
> [...]
> 
>>>> +    /* Create a socket 3 */
>>>> +    sockfd_3 = socket(AF_INET, SOCK_STREAM, 0);
>>>> +    ASSERT_LE(0, sockfd_3);
>>>> +    /* Allow reuse of local addresses */
>>>> +    ASSERT_EQ(0, setsockopt(sockfd_3, SOL_SOCKET, SO_REUSEADDR, 
>>>> &one, sizeof(one)));
>>>> +
>>>> +    /* Set socket 3 address parameters */
>>>> +    addr_3.sin_family = AF_INET;
>>>> +    addr_3.sin_port = htons(SOCK_PORT_3);
>>>> +    addr_3.sin_addr.s_addr = inet_addr(IP_ADDRESS);
>>>> +    memset(&(addr_3.sin_zero), '\0', 8);
>>>> +    /* Bind the socket 3 to IP address */
>>>> +    ASSERT_EQ(0, bind(sockfd_3, (struct sockaddr *)&addr_3, 
>>>> sizeof(addr_3)));
>>>
>>> Why is it allowed to bind to SOCK_PORT_3 whereas net_service_3 
>>> forbids it?
>>
>>    It's allowed cause net_service_3 has empty access field.
>>
>>     /* Empty allowed_access (i.e. deny rules) are ignored in network
>>      *  actions for SOCK_PORT_3 socket "object"
>>      */
>>      ASSERT_EQ(-1, landlock_add_rule(ruleset_fd,
>>                                      LANDLOCK_RULE_NET_SERVICE,
>>                                      &net_service_3, 0));
>>      ASSERT_EQ(ENOMSG, errno);
>>
>>    Applying this rule returns ENOMSG errno:
>>
>>    /* Informs about useless rule: empty allowed_access (i.e. deny rules)
>>     * are ignored in network actions
>>     */
>>          if (!net_service_attr.allowed_access) {
>>              err = -ENOMSG;
>>              goto out_put_ruleset;
>>          }
>>    This means binding socket 3 is not restricted.
>>    For path_beneath_attr.allowed_access = 0 there is the same logic.
> 
> I missed the ENOMSG check; the third rule has nothing to do with it. 
> However, because the ruleset handles bind and connect actions, they must 
> be denied by default. There is no rule allowing binding to SOCK_PORT_3. 
> Why is it allowed?
> 
> You can test with another SOCK_PORT_4, not covered by any rule. As for 
> SOCK_PORT_3, it must be forbidden to bind on it.

   Apllying the third rule (net_service_3.access is empty) returns ENOMSG
   error. That means a process hasn't been restricted by the third rule,
   cause during search  process in network rb_tree the process won't find
   the third rule, so binding to SOCK_PORT_3 is allowed.

   Maybe there is a misunderstanding here. You mean that if there is just
   only one network rule for a particular port has been applied to a
   process, other ports' networks actions are automatically restricted
   until they will be added into landlock newtwork rb_tree?
> .

WARNING: multiple messages have this Message-ID (diff)
From: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: linux-security-module@vger.kernel.org, netdev@vger.kernel.org,
	netfilter@vger.kernel.org, yusongping@huawei.com,
	artem.kuzin@huawei.com
Subject: Re: [RFC PATCH 2/2] landlock: selftests for bind and connect hooks
Date: Tue, 8 Feb 2022 06:01:34 +0300	[thread overview]
Message-ID: <9a77fc40-4463-4344-34d0-184d427d32cf@huawei.com> (raw)
In-Reply-To: <ae0fcafa-3e8d-d6f2-26a8-ae74dda8371c@digikod.net>



2/7/2022 3:49 PM, Mickaël Salaün пишет:
> 
> On 07/02/2022 08:11, Konstantin Meskhidze wrote:
>>
>>
>> 2/1/2022 9:31 PM, Mickaël Salaün пишет:
>>>
>>> On 24/01/2022 09:02, Konstantin Meskhidze wrote:
>>>> Support 4 tests for bind and connect networks actions:
>>>
>>> Good to see such tests!
>>>
>>>
>>>> 1. bind() a socket with no landlock restrictions.
>>>> 2. bind() sockets with landllock restrictions.
> 
> [...]
> 
>>>> + */
>>>> +
>>>> +#define _GNU_SOURCE
>>>> +#include <errno.h>
>>>> +#include <fcntl.h>
>>>> +#include <linux/landlock.h>
>>>> +#include <string.h>
>>>> +#include <sys/prctl.h>
>>>> +#include <sys/socket.h>
>>>> +#include <sys/types.h>
>>>> +#include <netinet/in.h>
>>>> +#include <arpa/inet.h>
>>>
>>> To make it determinisitic (and ease patching/diff/merging), you 
>>> should sort all the included files (in tests and in the kernel code).
>>
>>    Sorry. Did not get your point here. Could you explain in a bit more
>>    details please.
> 
> It will be easier to sort all the #include lines with the "sort -u" 
> command.

   Ok. I got it. Thanks.
> 
> [...]
> 
>>>> +    /* Create a socket 3 */
>>>> +    sockfd_3 = socket(AF_INET, SOCK_STREAM, 0);
>>>> +    ASSERT_LE(0, sockfd_3);
>>>> +    /* Allow reuse of local addresses */
>>>> +    ASSERT_EQ(0, setsockopt(sockfd_3, SOL_SOCKET, SO_REUSEADDR, 
>>>> &one, sizeof(one)));
>>>> +
>>>> +    /* Set socket 3 address parameters */
>>>> +    addr_3.sin_family = AF_INET;
>>>> +    addr_3.sin_port = htons(SOCK_PORT_3);
>>>> +    addr_3.sin_addr.s_addr = inet_addr(IP_ADDRESS);
>>>> +    memset(&(addr_3.sin_zero), '\0', 8);
>>>> +    /* Bind the socket 3 to IP address */
>>>> +    ASSERT_EQ(0, bind(sockfd_3, (struct sockaddr *)&addr_3, 
>>>> sizeof(addr_3)));
>>>
>>> Why is it allowed to bind to SOCK_PORT_3 whereas net_service_3 
>>> forbids it?
>>
>>    It's allowed cause net_service_3 has empty access field.
>>
>>     /* Empty allowed_access (i.e. deny rules) are ignored in network
>>      *  actions for SOCK_PORT_3 socket "object"
>>      */
>>      ASSERT_EQ(-1, landlock_add_rule(ruleset_fd,
>>                                      LANDLOCK_RULE_NET_SERVICE,
>>                                      &net_service_3, 0));
>>      ASSERT_EQ(ENOMSG, errno);
>>
>>    Applying this rule returns ENOMSG errno:
>>
>>    /* Informs about useless rule: empty allowed_access (i.e. deny rules)
>>     * are ignored in network actions
>>     */
>>          if (!net_service_attr.allowed_access) {
>>              err = -ENOMSG;
>>              goto out_put_ruleset;
>>          }
>>    This means binding socket 3 is not restricted.
>>    For path_beneath_attr.allowed_access = 0 there is the same logic.
> 
> I missed the ENOMSG check; the third rule has nothing to do with it. 
> However, because the ruleset handles bind and connect actions, they must 
> be denied by default. There is no rule allowing binding to SOCK_PORT_3. 
> Why is it allowed?
> 
> You can test with another SOCK_PORT_4, not covered by any rule. As for 
> SOCK_PORT_3, it must be forbidden to bind on it.

   Apllying the third rule (net_service_3.access is empty) returns ENOMSG
   error. That means a process hasn't been restricted by the third rule,
   cause during search  process in network rb_tree the process won't find
   the third rule, so binding to SOCK_PORT_3 is allowed.

   Maybe there is a misunderstanding here. You mean that if there is just
   only one network rule for a particular port has been applied to a
   process, other ports' networks actions are automatically restricted
   until they will be added into landlock newtwork rb_tree?
> .

  reply	other threads:[~2022-02-08  3:01 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-24  8:02 [RFC PATCH 0/2] landlock network implementation cover letter Konstantin Meskhidze
2022-01-24  8:02 ` Konstantin Meskhidze
2022-01-24  8:02 ` [RFC PATCH 1/2] landlock: TCP network hooks implementation Konstantin Meskhidze
2022-01-24  8:02   ` Konstantin Meskhidze
2022-01-25 14:17   ` Willem de Bruijn
2022-01-26  8:05     ` Konstantin Meskhidze
2022-01-26  8:05       ` Konstantin Meskhidze
2022-01-26 14:15       ` Willem de Bruijn
2022-01-29  3:12         ` Konstantin Meskhidze
2022-01-29  3:12           ` Konstantin Meskhidze
2022-01-31 17:14           ` Willem de Bruijn
2022-02-01 12:33             ` Mickaël Salaün
2022-02-07  2:31               ` Konstantin Meskhidze
2022-02-07  2:31                 ` Konstantin Meskhidze
2022-02-07 16:00                 ` Willem de Bruijn
2022-02-07 16:17                   ` Willem de Bruijn
2022-02-07 16:17                     ` Willem de Bruijn
2022-02-10  2:05                     ` Konstantin Meskhidze
2022-02-10  2:04                   ` Konstantin Meskhidze
2022-02-01 12:28         ` Mickaël Salaün
2022-02-07  2:35           ` Konstantin Meskhidze
2022-02-07  2:35             ` Konstantin Meskhidze
2022-02-01 12:13   ` Mickaël Salaün
2022-02-07 13:09     ` Konstantin Meskhidze
2022-02-07 13:09       ` Konstantin Meskhidze
2022-02-07 14:17       ` Mickaël Salaün
2022-02-08  7:55         ` Konstantin Meskhidze
2022-02-08  7:55           ` Konstantin Meskhidze
2022-02-08 12:09           ` Mickaël Salaün
2022-02-09  3:06             ` Konstantin Meskhidze
2022-02-09  3:06               ` Konstantin Meskhidze
2022-01-24  8:02 ` [RFC PATCH 2/2] landlock: selftests for bind and connect hooks Konstantin Meskhidze
2022-01-24  8:02   ` Konstantin Meskhidze
2022-02-01 18:31   ` Mickaël Salaün
2022-02-07  7:11     ` Konstantin Meskhidze
2022-02-07  7:11       ` Konstantin Meskhidze
2022-02-07 12:49       ` Mickaël Salaün
2022-02-08  3:01         ` Konstantin Meskhidze [this message]
2022-02-08  3:01           ` Konstantin Meskhidze
2022-02-08 12:17           ` Mickaël Salaün
2022-02-09  3:03             ` Konstantin Meskhidze
2022-02-09  3:03               ` Konstantin Meskhidze
2022-02-10 10:16               ` Mickaël Salaün
2022-02-24  3:18     ` Konstantin Meskhidze
2022-02-24  3:18       ` Konstantin Meskhidze
2022-02-24  9:55       ` Mickaël Salaün
2022-02-24 12:03         ` Konstantin Meskhidze
2022-02-24 12:03           ` Konstantin Meskhidze
2022-02-24 14:15           ` Mickaël Salaün
2022-02-25  2:44             ` Konstantin Meskhidze
2022-02-25  2:44               ` Konstantin Meskhidze
2022-02-01 17:53 ` [RFC PATCH 0/2] landlock network implementation cover letter Mickaël Salaün
2022-02-07 13:18   ` Konstantin Meskhidze
2022-02-07 13:18     ` Konstantin Meskhidze
2022-02-07 13:35     ` Mickaël Salaün
2022-02-08  3:53       ` Konstantin Meskhidze
2022-02-08  3:53         ` Konstantin Meskhidze

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=9a77fc40-4463-4344-34d0-184d427d32cf@huawei.com \
    --to=konstantin.meskhidze@huawei.com \
    --cc=artem.kuzin@huawei.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter@vger.kernel.org \
    --cc=yusongping@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.