netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Frederick Lawler <fred@cloudflare.com>,
	kpsingh@kernel.org, revest@chromium.org, jackmanb@chromium.org,
	ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
	kafai@fb.com, songliubraving@fb.com, yhs@fb.com,
	john.fastabend@gmail.com, jmorris@namei.org, serge@hallyn.com,
	stephen.smalley.work@gmail.com, eparis@parisplace.org,
	shuah@kernel.org, brauner@kernel.org, casey@schaufler-ca.com,
	bpf@vger.kernel.org, linux-security-module@vger.kernel.org,
	selinux@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	kernel-team@cloudflare.com, cgzones@googlemail.com,
	karl@bigbadwolfsecurity.com
Subject: Re: [PATCH v3 0/4] Introduce security_create_user_ns()
Date: Mon, 25 Jul 2022 18:53:26 -0400	[thread overview]
Message-ID: <CAHC9VhQXSXWv=+WYwU=Qq0w3rd+zOFPHL5yut1JdV2K=DDRmmg@mail.gmail.com> (raw)
In-Reply-To: <877d45kri4.fsf@email.froward.int.ebiederm.org>

On Fri, Jul 22, 2022 at 1:05 PM Eric W. Biederman <ebiederm@xmission.com> wrote:
> Frederick Lawler <fred@cloudflare.com> writes:
>
> > While creating a LSM BPF MAC policy to block user namespace creation, we
> > used the LSM cred_prepare hook because that is the closest hook to prevent
> > a call to create_user_ns().
>
> That description is wrong.  Your goal his is not to limit access to
> the user namespace.  Your goal is to reduce the attack surface of the
> kernel by not allowing some processes access to a user namespace.
>
> You have already said that you don't have concerns about the
> fundamentals of the user namespace, and what it enables only that
> it allows access to exploitable code.
>
> Achieving the protection you seek requires talking and thinking clearly
> about the goal.

Providing a single concrete goal for a LSM hook is always going to be
a challenge due to the nature of the LSM layer and the great unknown
of all the different LSMs that are implemented underneath the LSM
abstraction.  However, we can make some very general statements such
that up to this point the LSMs that have been merged into mainline
generally provide some level of access control, observability, or
both.  While that may change in the future (the LSM layer does not
attempt to restrict LSMs to just these two ideas), I think they are
"good enough" goals for this discussion.

In addition to thinking about these goals, I think it also important
to take a step back and think about the original motivation for the
LSM and why it, and Linux itself, has proven to be popular with
everything from the phone in your hand to the datacenter servers
powering ... pretty much everything :)  Arguably Linux has seen such
profound success because of its malleability; the open nature of the
kernel development process has allowed the Linux Kernel to adopt
capabilities well beyond what any one dev team could produce, and as
Linux continues to grow in adoption, its ability to flex into new use
cases only increases.  The kernel namespace concept is an excellent
example of this: virtualizing core kernel ideas, such as user
credentials, to provide better, safer solutions.  It is my belief that
the LSM layer is very much built around this same idea of abstracting
and extending core kernel concepts, in this case security controls, to
provide better solutions.  Integrating the LSM into the kernel's
namespaces is a natural fit, and one that is long overdue.

If we can't find a way to make everyone happy here, let's at least try
to find a way to make everyone "okay" with adding a LSM hook to the
user namespace.  If you want to NACK this approach Eric, that's okay,
but please provide some alternative paths forward that we can discuss.

-- 
paul-moore.com

  reply	other threads:[~2022-07-25 22:53 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-21 17:28 [PATCH v3 0/4] Introduce security_create_user_ns() Frederick Lawler
2022-07-21 17:28 ` [PATCH v3 1/4] security, lsm: " Frederick Lawler
2022-07-22  8:21   ` Christian Brauner
2022-07-21 17:28 ` [PATCH v3 2/4] bpf-lsm: Make bpf_lsm_userns_create() sleepable Frederick Lawler
2022-07-22  8:18   ` Christian Brauner
2022-07-21 17:28 ` [PATCH v3 3/4] selftests/bpf: Add tests verifying bpf lsm userns_create hook Frederick Lawler
2022-07-22  6:07   ` Martin KaFai Lau
2022-07-22 13:41     ` Frederick Lawler
2022-07-22  8:15   ` Christian Brauner
2022-07-21 17:28 ` [PATCH v3 4/4] selinux: Implement " Frederick Lawler
2022-07-22  6:11 ` [PATCH v3 0/4] Introduce security_create_user_ns() Martin KaFai Lau
2022-07-22 12:20   ` Paul Moore
2022-08-01 13:13     ` Frederick Lawler
2022-08-01 15:19       ` Paul Moore
2022-08-02 21:24         ` KP Singh
2022-08-03  1:49           ` Paul Moore
2022-08-01 15:25       ` Casey Schaufler
2022-08-01 16:34         ` Paul Moore
2022-08-02 21:27           ` KP Singh
2022-08-02 21:33     ` Eric W. Biederman
2022-08-03 15:20       ` Frederick Lawler
2022-07-22 17:05 ` Eric W. Biederman
2022-07-25 22:53   ` Paul Moore [this message]
2022-07-26 12:02   ` Djalal Harouni
2022-07-26 14:41   ` Ignat Korchagin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHC9VhQXSXWv=+WYwU=Qq0w3rd+zOFPHL5yut1JdV2K=DDRmmg@mail.gmail.com' \
    --to=paul@paul-moore.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=casey@schaufler-ca.com \
    --cc=cgzones@googlemail.com \
    --cc=daniel@iogearbox.net \
    --cc=ebiederm@xmission.com \
    --cc=eparis@parisplace.org \
    --cc=fred@cloudflare.com \
    --cc=jackmanb@chromium.org \
    --cc=jmorris@namei.org \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=karl@bigbadwolfsecurity.com \
    --cc=kernel-team@cloudflare.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=revest@chromium.org \
    --cc=selinux@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=shuah@kernel.org \
    --cc=songliubraving@fb.com \
    --cc=stephen.smalley.work@gmail.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).