From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 08AC1C05027 for ; Thu, 26 Jan 2023 06:27:04 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.96) (envelope-from ) id 1pKvih-0005Ct-0z; Thu, 26 Jan 2023 01:26:47 -0500 Received: from mout-p-201.mailbox.org ([80.241.56.171]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1pKvic-00058u-0L for kernelnewbies@kernelnewbies.org; Thu, 26 Jan 2023 01:26:42 -0500 Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4P2W254nkqz9spf for ; Thu, 26 Jan 2023 07:26:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1674714397; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=uk349i3VcuPL54frbF7jXF2mMcNo04yxznvaBNh9xVE=; b=SAcgIZHAuNqhn8VWHGAKRez4QQyeInvP4yIxcADWooX8eRZtd3nHd8Ed+dZ19PyMXjdeB3 16sNxh0QE2djaQqMFHHaX89m0CTVO4HLFli88VqtxI1dFY7nVV39/37inB0rcoCXfA1MlL SqIusvtxkXev0AGvh44b+srRUme8BQMRmac3ZMq2gz3EsG9LXU0JOVAmj8o2k7qzoqbOfK mWfo1hIbwKcmNQbujEn0kJ5bVBKutAfen4XkaZU/GNMEisPlR1ccskZ0GbEdLSQsdhtUNG 0ulhhHhPsfIxDthg52B/KZoofg5hoo31uodX9UD+gw6b9EQNuJMpDl0pqMMOjw== Date: Thu, 26 Jan 2023 07:26:35 +0100 From: Stefan Bavendiek To: kernelnewbies@kernelnewbies.org Subject: Isolating abstract sockets Message-ID: MIME-Version: 1.0 X-MBO-RS-META: ggt9do1hz1ps7sa1ec7367d3iijw81im X-MBO-RS-ID: 133c290be1b13a0c5f5 X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9102286730292254486==" Errors-To: kernelnewbies-bounces@kernelnewbies.org --===============9102286730292254486== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OXYAJ0E3pHrILN0C" Content-Disposition: inline --OXYAJ0E3pHrILN0C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Im trying to find a solution to a problem in the context of user space sandbox engineering on Linux and would appreciate any comments to guide me into the right direction in order to possible create a kernel patch that solves this problem: When building userspace application sandboxes, one issue that does not seem trivial to solve is the isolation of abstract sockets. While most IPC mechanism can be isolated by mechanisms like mount namespaces, abstract sockets are part of the network namespace. It is possible to isolate abstract sockets by using a new network namespace, however, unprivileged processes can only create a new empty network namespace, which removes network access as well and makes this useless for network clients. Same linux sandbox projects try to solve this by bridging the existing network interfaces into the new namespace or use something like slirp4netns to archive this, but this does not look like an ideal solution to this problem, especially since sandboxing should reduce the kernel attack surface without introducing more complexity. Aside from containers using namespaces, sandbox implementations based on seccomp and landlock would also run into the same problem, since landlock only provides file system isolation and seccomp cannot filter the path argument and therefore it can only be used to block new unix domain socket connections completely. Currently there does not seem to be any way to disable network namespaces in the kernel without also disabling unix domain sockets. The question is how to solve the issue of abstract socket isolation in a clean and efficient way, possibly even without namespaces. What would be the ideal way to implement a mechanism to disable abstract sockets either globally or even better, in the context of a process. Thank you - Stefan --OXYAJ0E3pHrILN0C Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEjLwAv8xLYF1doyZLdIuckz2DLQMFAmPSHQ4ACgkQdIuckz2D LQOaexAAgac7ShJjfhCpNAbKSi8AfHjODslH0M/qiSL4sOz9XbPutuNzqr5ysiVs xPbQ76Fd8DEnWSXlQALbGpM7rJ6lbV0oxCEsOvWdsFjylksna9z3VYm2mWcqA/3B SM0YxE9l/QG4oep+w8DYeii4vJSKTe3+Rno6D1kSIPwRKDg7o3PKbzfYmTSNDI4E moevg2e9WW/weQbkO158qSzWFG15FFaglavnPxADGUH5BsIg04BVXqnwvhHDfcmD e1/h8ZTXJxf0j4C5DxH/X+DxoVRGMkD15RNpuilySIMwochRRBBo7XSCpGySSeJJ 6P69YO9npWuMW4wAH+Md1rfo7Llp+JqRRqzgJWHeCXFABiv6qxbo2Q2yiIgw3Lxf CIcv67hIfQS5Evndvp+d9G/6bjhD0SsNJnVPg+odZB2McytdDuXDfvDfpLMOBPws GEhN7HubVnB8hk8MDQ53V3T+5qjUjlNdCHfrren/WJDQblZHH7ek/WPvMt0mzYQx IWmQzAXADESm38b5lbTMsFmW6g8G7wxjRSqyQPfKKlUpqnmkf9uu6Ad6glake98X d7oIl/vj85bcDfOqdIFgMYJ1RE1sf5oEGh58FA8lf56Vtgz1blXBrEEE09ZqToNs K1FjzFPBjEndoFExxUk1D90pt5iXwoJQwdy6sJQPJs6efvOWOII= =ZFfm -----END PGP SIGNATURE----- --OXYAJ0E3pHrILN0C-- --===============9102286730292254486== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies --===============9102286730292254486==--