Sandbox escape through missing restrictions for unix socket abstract namespace
Mickaël Salaün
mic at digikod.net
Mon Oct 23 20:42:39 UTC 2023
Hi Björn,
(CCing the Landlock and LSM mailing lists.)
On Mon, Oct 23, 2023 at 07:45:16PM +0000, Björn Roy Baron wrote:
> Hi Mickaël Salaün,
>
> Landlock doesn't have any restrictions for connecting to unix socket
> in the abstract namespace. This means that if you don't use seccomp to
> restrict access to the connect syscall or don't use a network
> namespace to isolate the abstract namespace, on systems with a gui a
> sandboxed process will be able to connect to the socket at
> @/tmp/.X11-unix/X0 to send key presses to Xorg to make the desktop
> environment run arbitrary processes outside of the sandbox. About a
> month ago I reported a sandbox escape in a sandboxing library which
> didn't have those restrictions.
Thanks for the heads up. Abstract unix sockets don't rely on the
filesystem. In fact the path used as an "abstract address" (after the
leading NULL character) is just a string from the kernel point of view.
There is then no way to properly tie it to filesystem access control
(contrary to unix socket files).
I agree that this might be confusing, but we need network restrictions
to control such socket. We are working on TCP access control [1] which
is a first step into being able to more broadly restrict network access.
We also talked about another complementary approach to more broadly
restrict socket creation [2].
[1] https://lore.kernel.org/r/20231016015030.1684504-1-konstantin.meskhidze@huawei.com
[2] https://lore.kernel.org/r/b8a2045a-e7e8-d141-7c01-bf47874c7930@digikod.net
>
> While this is not technically a violation of the documentation, it is
> surprising that you need seccomp or a network namespace in addition to
> Landlock to actually restrict filesystem access. In other places like
> ptrace access Landlock already does the necessary restrictions to
> prevent a program outside of the sandbox from getting hijacked.
The ptrace restrictions was a minimal requirement to not let processes
trivially bypass any sandbox. There are other missing access control
such as process signaling or networking. We'll get there but it takes
time. In the meantime, seccomp is a nice complement to Landlock to fill
these gaps.
About abstract unix socket control, I think it would be nice to be able
to scope access to such sockets the same way ptrace is limited (but this
time it would be opt-in). I think the same approach would fit well for
signaling too.
>
> I have written a write up of the security issue in the aforementioned
> sandboxing library which I want to publish on my blog. But I first
> want to give you the chance of adding a fix to Landlock if you
> consider this a bug in Landlock.
This is not a bug even if it might be surprising. We should probably
extend the documentation to explicitly list this example as a
limitation. Feel free to send a patch, or I'll add that to my todo list.
Feel free to share a link to your blog once you published your write up.
Regards,
Mickaël
>
> Cheers,
> Bjorn Baron
More information about the Linux-security-module-archive
mailing list