lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <7F90B59E-6AC3-4B82-8467-637945E181FB@fb.com> Date: Fri, 26 Aug 2022 16:57:19 +0000 From: Song Liu <songliubraving@...com> To: Paul Moore <paul@...l-moore.com> CC: "Eric W. Biederman" <ebiederm@...ssion.com>, "Serge E. Hallyn" <serge@...lyn.com>, Linus Torvalds <torvalds@...ux-foundation.org>, Frederick Lawler <fred@...udflare.com>, KP Singh <kpsingh@...nel.org>, "revest@...omium.org" <revest@...omium.org>, "jackmanb@...omium.org" <jackmanb@...omium.org>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, Martin Lau <kafai@...com>, Yonghong Song <yhs@...com>, John Fastabend <john.fastabend@...il.com>, James Morris <jmorris@...ei.org>, "stephen.smalley.work@...il.com" <stephen.smalley.work@...il.com>, "eparis@...isplace.org" <eparis@...isplace.org>, Shuah Khan <shuah@...nel.org>, "brauner@...nel.org" <brauner@...nel.org>, Casey Schaufler <casey@...aufler-ca.com>, bpf <bpf@...r.kernel.org>, LSM List <linux-security-module@...r.kernel.org>, "selinux@...r.kernel.org" <selinux@...r.kernel.org>, "open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, Networking <netdev@...r.kernel.org>, "kernel-team@...udflare.com" <kernel-team@...udflare.com>, "cgzones@...glemail.com" <cgzones@...glemail.com>, "karl@...badwolfsecurity.com" <karl@...badwolfsecurity.com>, "tixxdz@...il.com" <tixxdz@...il.com> Subject: Re: [PATCH v5 0/4] Introduce security_create_user_ns() > On Aug 26, 2022, at 8:02 AM, Paul Moore <paul@...l-moore.com> wrote: > > On Thu, Aug 25, 2022 at 6:42 PM Song Liu <songliubraving@...com> wrote: >>> On Aug 25, 2022, at 3:10 PM, Paul Moore <paul@...l-moore.com> wrote: >>> On Thu, Aug 25, 2022 at 5:58 PM Song Liu <songliubraving@...com> wrote: > > ... > >>>> I am new to user_namespace and security work, so please pardon me if >>>> anything below is very wrong. >>>> >>>> IIUC, user_namespace is a tool that enables trusted userspace code to >>>> control the behavior of untrusted (or less trusted) userspace code. >>>> Failing create_user_ns() doesn't make the system more reliable. >>>> Specifically, we call create_user_ns() via two paths: fork/clone and >>>> unshare. For both paths, we need the userspace to use user_namespace, >>>> and to honor failed create_user_ns(). >>>> >>>> On the other hand, I would echo that killing the process is not >>>> practical in some use cases. Specifically, allowing the application to >>>> run in a less secure environment for a short period of time might be >>>> much better than killing it and taking down the whole service. Of >>>> course, there are other cases that security is more important, and >>>> taking down the whole service is the better choice. >>>> >>>> I guess the ultimate solution is a way to enforce using user_namespace >>>> in the kernel (if it ever makes sense...). >>> >>> The LSM framework, and the BPF and SELinux LSM implementations in this >>> patchset, provide a mechanism to do just that: kernel enforced access >>> controls using flexible security policies which can be tailored by the >>> distro, solution provider, or end user to meet the specific needs of >>> their use case. >> >> In this case, I wouldn't call the kernel is enforcing access control. >> (I might be wrong). There are 3 components here: kernel, LSM, and >> trusted userspace (whoever calls unshare). > > The LSM layer, and the LSMs themselves are part of the kernel; look at > the changes in this patchset to see the LSM, BPF LSM, and SELinux > kernel changes. Explaining how the different LSMs work is quite a bit > beyond the scope of this discussion, but there is plenty of > information available online that should be able to serve as an > introduction, not to mention the kernel source itself. However, in > very broad terms you can think of the individual LSMs as somewhat > analogous to filesystem drivers, e.g. ext4, and the LSM itself as the > VFS layer. Thanks for the explanation. This matches my understanding with LSM. > >> AFAICT, kernel simply passes >> the decision made by LSM (BPF or SELinux) to the trusted userspace. It >> is up to the trusted userspace to honor the return value of unshare(). > > With a LSM enabled and enforcing a security policy on user namespace > creation, which appears to be the case of most concern, the kernel > would make a decision on the namespace creation based on various > factors (e.g. for SELinux this would be the calling process' security > domain and the domain's permission set as determined by the configured > security policy) and if the operation was rejected an error code would > be returned to userspace and the operation rejected. It is the exact > same thing as what would happen if the calling process is chrooted or > doesn't have a proper UID/GID mapping. Don't forget that the > create_user_ns() function already enforces a security policy and > returns errors to userspace; this patchset doesn't add anything new in > that regard, it just allows for a richer and more flexible security > policy to be built on top of the existing constraints. I believe I don't understand user namespace enough to agree or disagree here. I guess I should read more. Thanks, Song > >> If the userspace simply ignores unshare failures, or does not call >> unshare(CLONE_NEWUSER), kernel and LSM cannot do much about it, right? > > The process is still subject to any security policies that are active > and being enforced by the kernel. A malicious or misconfigured > application can still be constrained by the kernel using both the > kernel's legacy Discretionary Access Controls (DAC) as well as the > more comprehensive Mandatory Access Controls (MAC) provided by many of > the LSMs. > > -- > paul-moore.com
Powered by blists - more mailing lists