Received: by 2002:ab2:1689:0:b0:1f7:5705:b850 with SMTP id d9csp2111039lqa; Tue, 30 Apr 2024 08:25:03 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXxVwtaiISq21Jr4N51at2Os2uJ+5Do27JvO2sDDQGR1GV+bL7WBa9RTJsgUZXUpzmOk3WA1ElNMWpJKyxFVvy1oWS70s17gJ7OUhfMBg== X-Google-Smtp-Source: AGHT+IFF6EsxM2qgvgzD1QwJDwvCOHL9LpX2hHd0vVv2F5ypUajcBDO3fcDtcTZNES82mKSz/Mf8 X-Received: by 2002:a05:6214:20af:b0:6a0:b465:6c95 with SMTP id 15-20020a05621420af00b006a0b4656c95mr13479889qvd.4.1714490703144; Tue, 30 Apr 2024 08:25:03 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1714490703; cv=pass; d=google.com; s=arc-20160816; b=Ue0EotyRDzGd3lEcvVmUCcyFmS/0BJUoWPuBDjw3RZBHbSLsTXwZwmnFPc3b4jPlZX 20U+aKQeYHrS4I5MDxe527/zJhay+VEtuJXPxFxW9NGCy6mp5xP98LBmUmydVH5P7nVa +l/7hr5lbzxZGy6QO006RSfTdLMKO8m6nQurwaO9Lb79H0deQ9V/Ye8W9+vb8B6LqGlL FK2e8zbWD0hHj9xnySxZibIPtGKGuGaSxTKSGzwT6VWNLTcgFSjoFZNADAQOk07ZdRpG 7G+psWsySKS3I/nDcPxFRPXth69OkiA0te6OiBKu5Z7U8sD4H6N5koXFOas/gcDwwbLe ZBTg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=LOtjg1DrqqRAxQQUQgXAQVkUlshPfyMhRMykSNJLZf0=; fh=KU/frgkfacmlN70bTZds10Hl8wrr2/ZkADb0LtfOt9Q=; b=es0g+9Op9yD8txNk7Y9Q0Mq1qbBYaYSKSEpzujJaI0QeJJQXCI1v7nQOU9CqCW2Nl5 WG8sEhbjcD/tb8uT0f66RU7B82bbOQrpZyQXncyhAx1z1bE0kpfEVwe2b23Cq8Y3437T KgslXGaaqROgLJauN3Flf200tzYSn/gDDPcUK9kzc2mLA9OpI/zSi7M4DDQSVJ96k2nr ZbSXULcsLkP5W1l0KMi3amAhFfIOWYfZtFXH/ijNOWTe4wDm3HF9rdR25x483GpyWQ59 alW7E8g6lbamQhaQOt3UbiXdv/y9Qk0YLTkoBBe3g3+3TAoayeS7Y0hgRdXWA35I0ot4 xb1Q==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@digikod.net header.s=20191114 header.b=dCJFfiu8; arc=pass (i=1 spf=pass spfdomain=digikod.net dkim=pass dkdomain=digikod.net); spf=pass (google.com: domain of linux-kernel+bounces-164249-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-164249-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id q1-20020a056214194100b0069b4f599635si30699228qvk.231.2024.04.30.08.25.02 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Apr 2024 08:25:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-164249-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@digikod.net header.s=20191114 header.b=dCJFfiu8; arc=pass (i=1 spf=pass spfdomain=digikod.net dkim=pass dkdomain=digikod.net); spf=pass (google.com: domain of linux-kernel+bounces-164249-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-164249-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id C7EE91C22A2D for ; Tue, 30 Apr 2024 15:25:02 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8B9D0143750; Tue, 30 Apr 2024 15:24:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=digikod.net header.i=@digikod.net header.b="dCJFfiu8" Received: from smtp-bc0e.mail.infomaniak.ch (smtp-bc0e.mail.infomaniak.ch [45.157.188.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 370527711D for ; Tue, 30 Apr 2024 15:24:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.157.188.14 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714490692; cv=none; b=IJXRHy4fGrkH9899VzN/wYGJLqEGJHGjgdkr3T1iDZW2IoZasj/wPpZFceeNhF7oXXTQIxHkiCevZ7sV8+g8WHwPPinBJoW9U0NsP8a0mXV/ThXgQjRvi8gUql1psMNPEn7fBj4U4fC1gjp8coFh/WbeG0K25ZStOg/cjtlBhWQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714490692; c=relaxed/simple; bh=o9tw+r7HiK2cyxfIdnEKxzsdQ/OTiilNikfU3NSHVe0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MlMuWviOUxmzIH2aaIxiB2S0CyLw96R9NU/pWRGliL0G2Vq9dsJZTtlSiJo4RQa+IFyOtt809bTD2oNy3FemSZhp+Aw+yB2/M5fxR3jEYyucI6YpZ2qWXuukokAAEU07nmuj/jZpAOwd+mt4GrdDx9zgdrZcWWZJXmy9o64mgjA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net; spf=pass smtp.mailfrom=digikod.net; dkim=pass (1024-bit key) header.d=digikod.net header.i=@digikod.net header.b=dCJFfiu8; arc=none smtp.client-ip=45.157.188.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=digikod.net Received: from smtp-3-0000.mail.infomaniak.ch (smtp-3-0000.mail.infomaniak.ch [10.4.36.107]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4VTPBl21DwzwK5; Tue, 30 Apr 2024 17:24:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digikod.net; s=20191114; t=1714490687; bh=o9tw+r7HiK2cyxfIdnEKxzsdQ/OTiilNikfU3NSHVe0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dCJFfiu8WGMiQ53xbHZ1FW9HOnnmCs2WrkKqstQM5CEf2ab5pQQD3GVv0pmnZJhDL 8iD3bq+qImade0+0Vrdhs95JQMZcSwWLhABsB10SZlyjgeIzvySVt3evyecmyS2MXX wTmyf48w/uMNYgOBvz59alNnwDz6EJDyGZ02RIDg= Received: from unknown by smtp-3-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 4VTPBk2xCtzhtX; Tue, 30 Apr 2024 17:24:46 +0200 (CEST) Date: Tue, 30 Apr 2024 17:24:45 +0200 From: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= To: Tahera Fahimi Cc: Paul Moore , James Morris , "Serge E. Hallyn" , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, outreachy@lists.linux.dev, netdev@vger.kernel.org, =?utf-8?B?QmrDtnJu?= Roy Baron , Jann Horn , =?utf-8?Q?G=C3=BCnther?= Noack Subject: Re: [PATCH v2] landlock: Add abstract unix socket connect restrictions Message-ID: <20240411.ahgeefeiNg4i@digikod.net> References: <20240401.ieC2uqua5sha@digikod.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Infomaniak-Routing: alpha On Wed, Apr 10, 2024 at 04:24:30PM -0600, Tahera Fahimi wrote: > On Tue, Apr 02, 2024 at 11:53:09AM +0200, Mickaël Salaün wrote: > > Thanks for this patch. Please CC the netdev mailing list too, they may > > be interested by this feature. I also added a few folks that previously > > showed their interest for this feature. > > > > On Thu, Mar 28, 2024 at 05:12:13PM -0600, TaheraFahimi wrote: > > > Abstract unix sockets are used for local interprocess communication without > > > relying on filesystem. Since landlock has no restriction for connecting to > > > a UNIX socket in the abstract namespace, a sandboxed process can connect to > > > a socket outside the sandboxed environment. Access to such sockets should > > > be scoped the same way ptrace access is limited. > > > > This is good but it would be better to explain that Landlock doesn't > > currently control abstract unix sockets and that it would make sense for > > a sandbox. > > > > > > > > > > For a landlocked process to be allowed to connect to a target process, it > > > must have a subset of the target process’s rules (the connecting socket > > > must be in a sub-domain of the listening socket). This patch adds a new > > > LSM hook for connect function in unix socket with the related access rights. > > > > Because of compatibility reasons, and because Landlock should be > > flexible, we need to extend the user space interface. As explained in > > the GitHub issue, we need to add a new "scoped" field to the > > landlock_ruleset_attr struct. This field will optionally contain a > > LANDLOCK_RULESET_SCOPED_ABSTRACT_UNIX_SOCKET flag to specify that this > > ruleset will deny any connection from within the sandbox to its parents > > (i.e. any parent sandbox or not-sandboxed processes). > Thanks for the feedback. Here is what I understood, please correct me if > I am wrong. First, I should add another field to the > landlock_ruleset_attr (a field like handled_access_net, but for the unix > sockets) with a flag LANDLOCK_ACCESS_UNIX_CONNECT (it is a flag like > LANDLOCK_ACCESS_NET_CONNECT_TCP but fot the unix sockets connect). That was the initial idea, but after thinking more about it and talking with some users, I now think we can get a more generic interface. Because unix sockets, signals, and other IPCs are fully controlled by the kernel (contrary to inet sockets that get out of the system), we can add ingress and egress control according to the source and the destination. To control the direction we could add an LANDLOCK_ACCESS_DOM_UNIX_ABSTRACT_RECEIVE and a LANDLOCK_ACCESS_DOM_UNIX_ABSTRACT_SEND rights (these names are a bit long but at least explicit). To control the source and destination, it makes sense to use Landlock domain (i.e. sandboxes): LANDLOCK_DOMAIN_HIERARCHY_PARENT, LANDLOCK_DOMAIN_HIERARCHY_SELF, and LANDLOCK_DOMAIN_HIERARCHY_CHILD. This could be used by extending the landlock_ruleset_attr type and adding a new landlock_domain_hierarchy_attr type: struct landlock_ruleset_attr ruleset_attr = { .handled_access_dom = LANDLOCK_ACCESS_DOM_UNIX_ABSTRACT_RECEIVE | \ LANDLOCK_ACCESS_DOM_UNIX_ABSTRACT_SEND, } // Allows sending data to and receiving data from processes in the same // domain or a child domain, through abstract unix sockets. struct landlock_domain_hierarchy_attr dom_attr = { .allowed_access = LANDLOCK_ACCESS_DOM_UNIX_ABSTRACT_RECEIVE | \ LANDLOCK_ACCESS_DOM_UNIX_ABSTRACT_SEND, .relationship = LANDLOCK_DOMAIN_HIERARCHY_SELF | \ LANDLOCK_DOMAIN_HIERARCHY_CHILD, }; It should also work with other kind of IPCs: * LANDLOCK_ACCESS_DOM_UNIX_PATHNAME_RECEIVE/SEND (signal) * LANDLOCK_ACCESS_DOM_SIGNAL_RECEIVE/SEND (signal) * LANDLOCK_ACCESS_DOM_XSI_RECEIVE/SEND (XSI message queue) * LANDLOCK_ACCESS_DOM_MQ_RECEIVE/SEND (POSIX message queue) * LANDLOCK_ACCESS_DOM_PTRACE_RECEIVE/SEND (ptrace, which would be limited) What do you think?