From: Cyrill Gorcunov <gorcunov@gmail.com>
To: TongZhang <ztong@vt.edu>
Cc: Greg KH <gregkh@linuxfoundation.org>,
tglx@linutronix.de, akpm@linux-foundation.org,
linux@dominikbrodowski.net, ebiederm@xmission.com,
keescook@chromium.org, Dave.Martin@arm.com,
wolffhardt.schwabe@fau.de, yang.shi@linux.alibaba.com,
LKML <linux-kernel@vger.kernel.org>,
wenbo.s@samsung.com
Subject: Re: different capability from different namespace required for prctl_set_mm_exe_file
Date: Wed, 26 Sep 2018 09:59:06 +0300 [thread overview]
Message-ID: <20180926065906.GK15710@uranus> (raw)
In-Reply-To: <7D0EDE0E-ADFB-4B43-90BB-1845FD0FEAE8@vt.edu>
On Tue, Sep 25, 2018 at 07:37:14PM -0400, TongZhang wrote:
> I can see there are two problems,
>
> First: In kernel/sys.c:2117 capable(CAP_SYS_RESOURCE), seems that ns_capable should
> be used to check capability against user namespace, instead of init_user_ns. Because a
> process in a user namespace may call prctl system call and this should be checked against
> their user namespace capability instead of init_user_ns capability.
>
> Second: They should both require CAP_SYS_RESOURCE or CAP_SYS_ADMIN, is there any particular
> reasons for requiring different privilege?
Yes. We consider changing fields one by one in init_ns as an undesirable action,
mostly because some sysadmins/tools continue relay on this info for monitoring.
And requiring sysadmin here is too much: sysamin can do a way more than just
changing these members. In turn because userns is even more weak than init-ns
we require admin capability instead.
Again: non of the monitoring instrument should rely on the members this prctl
changes, they are not consistent and never was. But we still grip the privileges
here simply to not allow anyone change random members, at least in init-ns.
p.s. pleaase don't top post
prev parent reply other threads:[~2018-09-26 6:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-25 17:26 different capability from different namespace required for prctl_set_mm_exe_file Tong Zhang
2018-09-25 17:37 ` Greg KH
2018-09-25 18:34 ` Cyrill Gorcunov
2018-09-25 18:40 ` Greg KH
2018-09-25 18:54 ` Cyrill Gorcunov
2018-09-25 23:37 ` TongZhang
2018-09-26 6:59 ` Cyrill Gorcunov [this message]
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=20180926065906.GK15710@uranus \
--to=gorcunov@gmail.com \
--cc=Dave.Martin@arm.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=tglx@linutronix.de \
--cc=wenbo.s@samsung.com \
--cc=wolffhardt.schwabe@fau.de \
--cc=yang.shi@linux.alibaba.com \
--cc=ztong@vt.edu \
/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