From: "Serge E. Hallyn" <serge@hallyn.com>
To: Jann Horn <jannh@google.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
Stefan Bavendiek <stefan.bavendiek@mailbox.org>,
kernel-hardening@lists.openwall.com,
linux-hardening@vger.kernel.org
Subject: Re: Isolating abstract sockets
Date: Wed, 25 Oct 2023 12:22:35 -0500 [thread overview]
Message-ID: <20231025172235.GA345747@mail.hallyn.com> (raw)
In-Reply-To: <CAG48ez2DF4unFq7wXqHVdUg+o_VYee012v0hUiGTbfnTpsPi0w@mail.gmail.com>
On Wed, Oct 25, 2023 at 07:10:07PM +0200, Jann Horn wrote:
> On Tue, Oct 24, 2023 at 3:46 PM Serge E. Hallyn <serge@hallyn.com> wrote:
> > Disabling them altogether would break lots of things depending on them,
> > like X :) (@/tmp/.X11-unix/X0).
>
> FWIW, X can connect over both filesystem-based unix domain sockets and
> abstract unix domain sockets. When a normal X client tries to connect
> to the server, it'll try a bunch of stuff, including an abstract unix
> socket address, a filesystem-based unix socket address, and TCP:
>
> $ DISPLAY=:12345 strace -f -e trace=connect xev >/dev/null
> connect(3, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X12345"}, 24)
> = -1 ECONNREFUSED (Connection refused)
> connect(3, {sa_family=AF_UNIX, sun_path="/tmp/.X11-unix/X12345"}, 110)
> = -1 ENOENT (No such file or directory)
> [...]
> connect(3, {sa_family=AF_INET, sin_port=htons(18345),
> sin_addr=inet_addr("127.0.0.1")}, 16) = 0
> connect(3, {sa_family=AF_INET6, sin6_port=htons(18345),
> inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=htonl(0),
> sin6_scope_id=0}, 28) = 0
> connect(3, {sa_family=AF_INET6, sin6_port=htons(18345),
> inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=htonl(0),
> sin6_scope_id=0}, 28) = -1 ECONNREFUSED (Connection refused)
> connect(3, {sa_family=AF_INET, sin_port=htons(18345),
> sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection
> refused)
>
> And the X server normally listens on both an abstract and a
> filesystem-based unix socket address (see "netstat --unix -lnp").
>
> So rejecting abstract unix socket connections shouldn't prevent an X
> client from connecting to the X server, I think.
Well it was just an example :) Dbus is another. But maybe all
the users of abstract unix sockets will fall back gracefully to
something else. That'd be nice.
For X, abstract really doesn't even make sense to me. Has it always
supported that?
next prev parent reply other threads:[~2023-10-25 17:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-18 19:29 Isolating abstract sockets Stefan Bavendiek
2023-10-24 13:46 ` Serge E. Hallyn
2023-10-24 14:05 ` Boris Lukashev
2023-10-24 14:15 ` Serge E. Hallyn
2023-10-24 15:55 ` Boris Lukashev
2023-10-24 16:11 ` Serge E. Hallyn
2023-10-24 14:14 ` Paul Moore
2023-10-24 14:18 ` Serge E. Hallyn
2023-10-24 14:29 ` Paul Moore
2023-10-24 16:07 ` Serge E. Hallyn
2023-10-25 11:54 ` Mickaël Salaün
2023-10-31 20:40 ` Stefan Bavendiek
2023-11-01 10:56 ` Mickaël Salaün
2023-11-01 16:23 ` Jann Horn
2023-11-02 14:50 ` Mickaël Salaün
2023-10-25 17:10 ` Jann Horn
2023-10-25 17:22 ` Serge E. Hallyn [this message]
2023-10-25 17:41 ` Jann Horn
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=20231025172235.GA345747@mail.hallyn.com \
--to=serge@hallyn.com \
--cc=jannh@google.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-hardening@vger.kernel.org \
--cc=stefan.bavendiek@mailbox.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).