From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4E27B14F131 for ; Mon, 10 Jun 2024 20:12:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718050350; cv=none; b=Eqg+2li87mMj0L9M/EANXsi9RpjX9ts+FsSJbDfnj57udddEwdflNUvoW+KRytYHDFU54v14mk1EFp4z086MACZy1HSepiFNMXtxJTaZgeHjAngW7CuKchwCvvj9ePkV8OzwcDU38B6PMDXIawLEzVkEQg5ICvzSMN0UH3dW/Rc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718050350; c=relaxed/simple; bh=b7+MwoWNMLPQ7YyhI/4+4s4P3K4STGUIbLhPZG0Mamc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=U1Ksp9aMobKGY5Nomh1ky6KiPYtSN150cpkubwM9YSQ/S0WiBGXOgi/DnELIcnwBBHtJqxZoHjJvujWFsQNDElFdhHe6QHBmqC+gi/3N28ErHv2shcjFCzAkGXG2gcRrFXC1yK+TNaQ+r7Wh4NAMG9NJ5DNsyuHlle92QUxaULY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=toxicpanda.com; spf=none smtp.mailfrom=toxicpanda.com; dkim=pass (2048-bit key) header.d=toxicpanda-com.20230601.gappssmtp.com header.i=@toxicpanda-com.20230601.gappssmtp.com header.b=LYwY4ug2; arc=none smtp.client-ip=209.85.128.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=toxicpanda.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=toxicpanda.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=toxicpanda-com.20230601.gappssmtp.com header.i=@toxicpanda-com.20230601.gappssmtp.com header.b="LYwY4ug2" Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-62a2424ec39so49314717b3.1 for ; Mon, 10 Jun 2024 13:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20230601.gappssmtp.com; s=20230601; t=1718050348; x=1718655148; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=q8U88OhWZh1tCo+0WQ1tID8xLxoIwnJftDZHFtRwK3o=; b=LYwY4ug2iL/vJ4DIUm0/Hp2MvpGURHFsHfCR8hKgvsmAqgzRPxBeFZzp5Tfo48EbCo Euj3YFKE98R3xDK+TVi4X08MQrChZxoR0ZdwAIKYcBEyuT6J6pRA6MFIWpmGlK1QH6yk ayaE24UINt0NKI07iU6nbvvP+ur4CK0DddjWE0Gtpl8JlrD2yRSechl/xjLYVx0XPb6G i76retKit/NIZmraE8AuogV1B4ponmQt72v7gY3tzehh7ckEOuDJ8LHGOKzXVFo5n2E+ 4LMkjHweMxF1v6LeN1NaZpvEMI8QBe5KxGttDTh645mywME2cc7oJs1j5M/rPYABPg7M UNcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718050348; x=1718655148; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=q8U88OhWZh1tCo+0WQ1tID8xLxoIwnJftDZHFtRwK3o=; b=CXxdlMpM964S7dH8lEJxNLKOyyiVH3/Mk4yQnJ9jTag0Bra0iu7/o80mRDQRE/Ru2K O4oYx2wnclPPzVk59n1TQn3THlNjVCUKQkazckHv3VlHLiC6JBrdVk+ZMhI1LyWtvfA1 BIO7JNwqPhlAw+LXvb4QTIOqT3Pi4/T1wq9DHxMxy6rwEypIAcyCmOKLMDLLlhByrrEi yfT9gTKnOov2SQr26+q+6oYavw36skFLXamAxzEBqmwVAhO0M2/ZK5dMGA8D7BNwiUBd ABydnGCwxe/CjtfRCxSZD5892GRgfYHOajDgRHB/7mGmcJMMqFpaVT+F74NI9BHwAru3 Bg0A== X-Forwarded-Encrypted: i=1; AJvYcCXGUj6s2ppTKDyn0B9TfeAZCoslKtjjub0cGx/oGlaHkjIXs4uIieX01xxKClF3P191A6q/+vSgBt7xLUBBuyQ4i3X7 X-Gm-Message-State: AOJu0YzZnEvSdxxZ0X1rvrsiWyNxtF7I0mSO36o3THFXkf0g7dV7Np9B z5tFIliTNZsetZ4/l8Ga+yDtIa9jzwapbeaACpiybJaBOtmWGLZEGDh6xsF2Ifx0Gr2P92AmAlU dhkA= X-Google-Smtp-Source: AGHT+IHAq2uat/BxStlvycvWIMemf9chq6bKvr5RgwVh7JekY7oKEJ33MFsCJYBOa4s18l+17nIrDA== X-Received: by 2002:a81:ef0e:0:b0:61a:f206:bad6 with SMTP id 00721157ae682-62cd55f6755mr90104707b3.30.1718050348318; Mon, 10 Jun 2024 13:12:28 -0700 (PDT) Received: from localhost (syn-076-182-020-124.res.spectrum.com. [76.182.20.124]) by smtp.gmail.com with ESMTPSA id 00721157ae682-62ccaef2825sm17372997b3.139.2024.06.10.13.12.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jun 2024 13:12:27 -0700 (PDT) Date: Mon, 10 Jun 2024 16:12:27 -0400 From: Josef Bacik To: Jonathan Calmels Cc: brauner@kernel.org, ebiederm@xmission.com, Jonathan Corbet , Paul Moore , James Morris , "Serge E. Hallyn" , KP Singh , Matt Bobrowski , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , Stanislav Fomichev , Hao Luo , Jiri Olsa , Luis Chamberlain , Kees Cook , Joel Granados , John Johansen , David Howells , Jarkko Sakkinen , Stephen Smalley , Ondrej Mosnacek , Mykola Lysenko , Shuah Khan , containers@lists.linux.dev, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-security-module@vger.kernel.org, bpf@vger.kernel.org, apparmor@lists.ubuntu.com, keyrings@vger.kernel.org, selinux@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v2 0/4] Introduce user namespace capabilities Message-ID: <20240610201227.GD235772@perftesting> References: <20240609104355.442002-1-jcalmels@3xx0.net> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240609104355.442002-1-jcalmels@3xx0.net> On Sun, Jun 09, 2024 at 03:43:33AM -0700, Jonathan Calmels wrote: > This patch series introduces a new user namespace capability set, as > well as some plumbing around it (i.e. sysctl, secbit, lsm support). > > First patch goes over the motivations for this as well as prior art. > > In summary, while user namespaces are a great success today in that they > avoid running a lot of code as root, they also expand the attack surface > of the kernel substantially which is often abused by attackers. > Methods exist to limit the creation of such namespaces [1], however, > application developers often need to assume that user namespaces are > available for various tasks such as sandboxing. Thus, instead of > restricting the creation of user namespaces, we offer ways for userspace > to limit the capabilities granted to them. > > Why a new capability set and not something specific to the userns (e.g. > ioctl_ns)? > > 1. We can't really expect userspace to patch every single callsite > and opt-in this new security mechanism. > > 2. We don't necessarily want policies enforced at said callsites. > For example a service like systemd-machined or a PAM session need to > be able to place restrictions on any namespace spawned under it. > > 3. We would need to come up with inheritance rules, querying > capabilities, etc. At this point we're just reinventing capability > sets. > > 4. We can easily define interactions between capability sets, thus > helping with adoption (patch 2 is an example of this) > > Some examples of how this could be leveraged in userspace: > > - Prevent user from getting CAP_NET_ADMIN in user namespaces under SSH: > echo "auth optional pam_cap.so" >> /etc/pam.d/sshd > echo "!cap_net_admin $USER" >> /etc/security/capability.conf > capsh --secbits=$((1 << 8)) -- -c /usr/sbin/sshd > > - Prevent containers from ever getting CAP_DAC_OVERRIDE: > systemd-run -p CapabilityBoundingSet=~CAP_DAC_OVERRIDE \ > -p SecureBits=userns-strict-caps \ > /usr/bin/dockerd > systemd-run -p UserNSCapabilities=~CAP_DAC_OVERRIDE \ > /usr/bin/incusd > > - Kernel could be vulnerable to CAP_SYS_RAWIO exploits, prevent it: > sysctl -w cap_bound_userns_mask=0x1fffffdffff > > - Drop CAP_SYS_ADMIN for this shell and all the user namespaces below it: > bwrap --unshare-user --cap-drop CAP_SYS_ADMIN /bin/sh > Where are the tests for this patchset? I see you updated the bpf tests for the bpf lsm bits, but there's nothing to validate this new behavior or exercise the new ioctl you've added. Thanks, Josef