From: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: "Mickaël Salaün" <mic@digikod.net>,
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 1/2] landlock: TCP network hooks implementation
Date: Thu, 10 Feb 2022 05:05:57 +0300 [thread overview]
Message-ID: <fcbeec21-d6ab-caa2-4eb0-09d712536c2d@huawei.com> (raw)
In-Reply-To: <CA+FuTSc6BfWKu1taQr7wPoQ4VJg3Au1PH-rbTa71-srLzARL-A@mail.gmail.com>
2/7/2022 7:17 PM, Willem de Bruijn пишет:
>>> If bind() function has already been restricted so the following
>>> listen() function is automatically banned. I agree with Mickaёl about
>>> the usecase here. Why do we need new-bound socket with restricted listening?
>>
>> The intended use-case is for a privileged process to open a connection
>> (i.e., bound and connected socket) and pass that to a restricted
>> process. The intent is for that process to only be allowed to
>> communicate over this pre-established channel.
>>
>> In practice, it is able to disconnect (while staying bound) and
>> elevate its privileges to that of a listening server:
>>
>> static void child_process(int fd)
>> {
>> struct sockaddr addr = { .sa_family = AF_UNSPEC };
>> int client_fd;
>>
>> if (listen(fd, 1) == 0)
>> error(1, 0, "listen succeeded while connected");
>>
>> if (connect(fd, &addr, sizeof(addr)))
>> error(1, errno, "disconnect");
>>
>> if (listen(fd, 1))
>> error(1, errno, "listen");
>>
>> client_fd = accept(fd, NULL, NULL);
>> if (client_fd == -1)
>> error(1, errno, "accept");
>>
>> if (close(client_fd))
>> error(1, errno, "close client");
>> }
>>
>> int main(int argc, char **argv)
>> {
>> struct sockaddr_in6 addr = { 0 };
>> pid_t pid;
>> int fd;
>>
>> fd = socket(PF_INET6, SOCK_STREAM, 0);
>> if (fd == -1)
>> error(1, errno, "socket");
>>
>> addr.sin6_family = AF_INET6;
>> addr.sin6_addr = in6addr_loopback;
>>
>> addr.sin6_port = htons(8001);
>> if (bind(fd, (void *)&addr, sizeof(addr)))
>> error(1, errno, "bind");
>>
>> addr.sin6_port = htons(8000);
>> if (connect(fd, (void *)&addr, sizeof(addr)))
>> error(1, errno, "connect");
>>
>> pid = fork();
>> if (pid == -1)
>> error(1, errno, "fork");
>>
>> if (pid)
>> wait(NULL);
>> else
>> child_process(fd);
>>
>> if (close(fd))
>> error(1, errno, "close");
>>
>> return 0;
>> }
>>
>> It's fine to not address this case in this patch series directly, of
>> course. But we should be aware of the AF_UNSPEC loophole.
>
> I did just notice that with autobind (i.e., without the explicit call
> to bind), the socket gets a different local port after listen. So
> internally a bind call may be made, which may or may not be correctly
> handled by the current landlock implementation already:
Thanks again. I will check it out.
>
> +static void show_local_port(int fd)
> +{
> + char addr_str[INET6_ADDRSTRLEN];
> + struct sockaddr_in6 addr = { 0 };
> + socklen_t alen;
> +
> + alen = sizeof(addr);
> + if (getsockname(fd, (void *)&addr, &alen))
> + error(1, errno, "getsockname");
> +
> + if (addr.sin6_family != AF_INET6)
> + error(1, 0, "getsockname: family");
> +
> + if (!inet_ntop(AF_INET6, &addr.sin6_addr, addr_str, sizeof(addr_str)))
> + error(1, errno, "inet_ntop");
> + fprintf(stderr, "server: %s:%hu\n", addr_str, ntohs(addr.sin6_port));
> +
> +}
> +
> @@ -23,6 +42,8 @@ static void child_process(int fd)
> if (connect(fd, &addr, sizeof(addr)))
> error(1, errno, "disconnect");
>
> + show_local_port(fd);
> +
> if (listen(fd, 1))
> error(1, errno, "listen");
>
> + show_local_port(fd);
> +
>
> @@ -47,10 +68,6 @@ int main(int argc, char **argv)
> addr.sin6_family = AF_INET6;
> addr.sin6_addr = in6addr_loopback;
>
> - addr.sin6_port = htons(8001);
> - if (bind(fd, (void *)&addr, sizeof(addr)))
> - error(1, errno, "bind");
> -
> addr.sin6_port = htons(8000);
> if (connect(fd, (void *)&addr, sizeof(addr)))
> error(1, errno, "connect");
> .
next prev parent reply other threads:[~2022-02-10 2:08 UTC|newest]
Thread overview: 38+ 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 ` [RFC PATCH 1/2] landlock: TCP network hooks implementation Konstantin Meskhidze
2022-01-25 14:17 ` Willem de Bruijn
2022-01-26 8:05 ` Konstantin Meskhidze
2022-01-26 14:15 ` Willem de Bruijn
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 16:00 ` Willem de Bruijn
2022-02-07 16:17 ` Willem de Bruijn
2022-02-10 2:05 ` Konstantin Meskhidze [this message]
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-01 12:13 ` Mickaël Salaün
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 12:09 ` Mickaël Salaün
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-02-01 18:31 ` Mickaël Salaün
2022-02-07 7:11 ` Konstantin Meskhidze
2022-02-07 12:49 ` Mickaël Salaün
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-10 10:16 ` Mickaël Salaün
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 14:15 ` Mickaël Salaün
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:35 ` Mickaël Salaün
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=fcbeec21-d6ab-caa2-4eb0-09d712536c2d@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=willemdebruijn.kernel@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).