From: ebiederm@xmission.com (Eric W. Biederman)
To: Prakash Sangappa <prakash.sangappa@oracle.com>
Cc: linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
tglx@linutronix.de, peterz@infradead.org, serge@hallyn.com
Subject: Re: [RESEND RFC PATCH 1/1] Selectively allow CAP_SYS_NICE capability inside user namespaces
Date: Thu, 21 Nov 2019 15:27:49 -0600 [thread overview]
Message-ID: <87wobszzqi.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <1574096478-11520-2-git-send-email-prakash.sangappa@oracle.com> (Prakash Sangappa's message of "Mon, 18 Nov 2019 09:01:18 -0800")
Prakash Sangappa <prakash.sangappa@oracle.com> writes:
> Allow CAP_SYS_NICE to take effect for processes having effective uid of a
> root user from init namespace.
>
> Signed-off-by: Prakash Sangappa <prakash.sangappa@oracle.com>
> ---
> kernel/sched/core.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 7880f4f..628bd46 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4548,6 +4548,8 @@ int can_nice(const struct task_struct *p, const int nice)
> int nice_rlim = nice_to_rlimit(nice);
>
> return (nice_rlim <= task_rlimit(p, RLIMIT_NICE) ||
> + (ns_capable(__task_cred(p)->user_ns, CAP_SYS_NICE) &&
> + uid_eq(current_euid(), GLOBAL_ROOT_UID)) ||
> capable(CAP_SYS_NICE));
> }
>
> @@ -4784,7 +4786,9 @@ static int __sched_setscheduler(struct task_struct *p,
> /*
> * Allow unprivileged RT tasks to decrease priority:
> */
> - if (user && !capable(CAP_SYS_NICE)) {
> + if (user && !(ns_capable(__task_cred(p)->user_ns, CAP_SYS_NICE) &&
> + uid_eq(current_euid(), GLOBAL_ROOT_UID)) &&
> + !capable(CAP_SYS_NICE)) {
> if (fair_policy(policy)) {
> if (attr->sched_nice < task_nice(p) &&
> !can_nice(p, attr->sched_nice))
I remember looking at this before. I don't remember if I commented.
1) Having GLOBAL_ROOT_UID in a user namespace is A Bad Idea™.
Definitely not something we should make special case for.
That configuration is almost certainly a privilege escalation waiting
to happen.
2) If I read the other thread correctly there was talk about setting the
nice levels of processes in other containers. Ouch!
The only thing I can think that makes any sense at all is to allow
setting the nice levels of the processes in your own container.
I can totally see having a test to see if a processes credentials are
in the caller's user namespace or a child of caller's user namespace
and allowing admin level access if the caller has the appropriate
caps in their user namespace.
But in this case I don't see anything preventing the admin in a
container from using the ordinary nice levels on a task. You are
unlocking the nice levels reserved for the system administrator
for special occassions. I don't see how that makes any sense
to do from inside a container.
The design goal of user namespaces (assuming a non-buggy kernel) is to
ensure user namespaces give a user no more privileges than the user had
before creating a user namespace. In this case you are granting a user
who creates a user namespace the ability to change nice levels on all
process in the system (limited to users whose uid happens to be
GLOBAL_ROOT_UID). But still this is effectively a way to get
CAP_SYS_NICE back if it was dropped.
As a violation of security policy this change simply can not be allowed.
The entire idiom: "ns_capable(__task_cred(p)->user_ns, ...)" is a check
that provides no security.
Eric
next prev parent reply other threads:[~2019-11-21 21:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-18 17:01 [RESEND RFC PATCH 0/1] CAP_SYS_NICE inside user namespace Prakash Sangappa
2019-11-18 17:01 ` [RESEND RFC PATCH 1/1] Selectively allow CAP_SYS_NICE capability inside user namespaces Prakash Sangappa
2019-11-18 19:30 ` Jann Horn
2019-11-19 0:46 ` prakash.sangappa
2019-11-21 21:27 ` Eric W. Biederman [this message]
2019-11-22 1:45 ` Prakash Sangappa
2020-01-08 21:23 ` prakash.sangappa
2019-11-18 19:36 ` [RESEND RFC PATCH 0/1] CAP_SYS_NICE inside user namespace Jann Horn
2019-11-18 20:34 ` Prakash Sangappa
2019-11-21 18:33 ` Enrico Weigelt, metux IT consult
2019-11-22 1:54 ` Prakash Sangappa
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=87wobszzqi.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=prakash.sangappa@oracle.com \
--cc=serge@hallyn.com \
--cc=tglx@linutronix.de \
/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).