On Aug 26, 2022, at 2:00 PM, Serge E. Hallyn [off-list ref] wrote:

On Fri, Aug 26, 2022 at 05:00:51PM +0000, Song Liu wrote:

quoted

quoted

On Aug 26, 2022, at 8:24 AM, Serge E. Hallyn [off-list ref] wrote:

On Thu, Aug 25, 2022 at 09:58:46PM +0000, Song Liu wrote:

quoted

quoted

On Aug 25, 2022, at 12:19 PM, Paul Moore [off-list ref] wrote:

On Thu, Aug 25, 2022 at 2:15 PM Eric W. Biederman [off-list ref] wrote:

quoted

Paul Moore [off-list ref] writes:

quoted

On Fri, Aug 19, 2022 at 10:45 AM Serge E. Hallyn [off-list ref] wrote:

quoted

I am hoping we can come up with
"something better" to address people's needs, make everyone happy, and
bring forth world peace.  Which would stack just fine with what's here
for defense in depth.

You may well not be interested in further work, and that's fine.  I need
to set aside a few days to think on this.

I'm happy to continue the discussion as long as it's constructive; I
think we all are.  My gut feeling is that Frederick's approach falls
closest to the sweet spot of "workable without being overly offensive"
(*cough*), but if you've got an additional approach in mind, or an
alternative approach that solves the same use case problems, I think
we'd all love to hear about it.

I would love to actually hear the problems people are trying to solve so
that we can have a sensible conversation about the trade offs.

Here are several taken from the previous threads, it's surely not a
complete list, but it should give you a good idea:

https://lore.kernel.org/linux-security-module/CAHC9VhQnPAsmjmKo-e84XDJ1wmaOFkTKPjjztsOa9Yrq+AeAQA@mail.gmail.com/ (local)

quoted

As best I can tell without more information people want to use
the creation of a user namespace as a signal that the code is
attempting an exploit.

Some use cases are like that, there are several other use cases that
go beyond this; see all of our previous discussions on this
topic/patchset.  As has been mentioned before, there are use cases
that require improved observability, access control, or both.

quoted

As such let me propose instead of returning an error code which will let
the exploit continue, have the security hook return a bool.  With true
meaning the code can continue and on false it will trigger using SIGSYS
to terminate the program like seccomp does.

Having the kernel forcibly exit the process isn't something that most
LSMs would likely want.  I suppose we could modify the hook/caller so
that *if* an LSM wanted to return SIGSYS the system would kill the
process, but I would want that to be something in addition to
returning an error code like LSMs normally do (e.g. EACCES).

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. 

No.  user namespaces are not a way for more trusted code to control the
behavior of less trusted code.

Hmm.. In this case, I think I really need to learn more. 

Thanks for pointing out my misunderstanding.

(I thought maybe Eric would chime in with a better explanation, but I'll
fill it in for now :)

One of the main goals of user namespaces is to allow unprivileged users
to do things like chroot and mount, which are very useful development
tools, without needing admin privileges.  So it's almost the opposite
of what you said: rather than to enable trusted userspace code to control
the behavior of less trusted code, it's to allow less privileged code to
do things which do not affect other users, without having to assume *more*
privilege.

Thanks for the explanation! 

To be precise, the goals were:

1. uid mapping - allow two users to both "use uid 500" without conflicting
2. provide (unprivileged) users privilege over their own resources
3. absolutely no extra privilege over other resources
4. be able to nest

Now I have better idea about "what". But I am not quite sure about how to do
it. I will do more homework, and probably come back with more questions. :)

While (3) was technically achieved, the problem we have is that
(2) provides unprivileged users the ability to exercise kernel code
which they previously could not.

Do you mean this one?

"""
I think the problem is that it seems
you can pretty reliably get a root shell at some point in the future
by creating a user namespace, leaving it open for a bit, and waiting
for a new announcement of the latest netfilter or whatever exploit
that requires root in a user namespace.  Then go back to your userns
shell and run the exploit.
"""

Please don't share how to do it yet. I want to use it as a test for my study. :)

Thanks again!

Song