From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: "Konstantin Meskhidze" <konstantin.meskhidze@huawei.com>,
"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: Mon, 7 Feb 2022 11:17:13 -0500 [thread overview]
Message-ID: <CA+FuTSc6BfWKu1taQr7wPoQ4VJg3Au1PH-rbTa71-srLzARL-A@mail.gmail.com> (raw)
In-Reply-To: <CA+FuTScaoby-=xRKf_Dz3koSYHqrMN0cauCg4jMmy_nDxwPADA@mail.gmail.com>
> > 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:
+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-07 16:33 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 [this message]
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-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=CA+FuTSc6BfWKu1taQr7wPoQ4VJg3Au1PH-rbTa71-srLzARL-A@mail.gmail.com \
--to=willemdebruijn.kernel@gmail.com \
--cc=artem.kuzin@huawei.com \
--cc=konstantin.meskhidze@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 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).