All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: yangshukui <yangshukui@huawei.com>
Cc: selinux@tycho.nsa.gov, linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	"Guohanjun (Hanjun Guo)" <guohanjun@huawei.com>,
	"'Qiang Huang'" <h.huangqiang@huawei.com>,
	Lizefan <lizefan@huawei.com>, "miaoxie (A)" <miaoxie@huawei.com>,
	Zhangdianfang <zhangdianfang@huawei.com>,
	paul@paul-moore.com, sds@tycho.nsa.gov, eparis@parisplace.org,
	james.l.morris@oracle.com, ebiederm@xmission.com,
	serge.hallyn@ubuntu.com
Subject: Re: SELinux lead to soft lockup when pid 1 proceess reap child
Date: Mon, 9 Jan 2017 19:29:15 +0100	[thread overview]
Message-ID: <20170109182915.GC8972@redhat.com> (raw)
In-Reply-To: <20170109181225.GB8972@redhat.com>

Seriously, could someone explain why do we need the security_task_wait()
hook at all?


On 01/09, Oleg Nesterov wrote:
>
> On 01/09, yangshukui wrote:
> >
> > --- a/security/selinux/hooks.c
> > +++ b/security/selinux/hooks.c
> > @@ -3596,6 +3596,9 @@ static int selinux_task_kill(struct task_struct *p,
> > struct siginfo *info,
> >
> >  static int selinux_task_wait(struct task_struct *p)
> >  {
> > +       if (pid_vnr(task_tgid(current)) == 1){
> > +                return 0;
> 
> this check is not really correct, it can be a sub-thread... Doesn't matter,
> please see below.
> 
> > +       }
> >         return task_has_perm(p, current, PROCESS__SIGCHLD);
> >  }
> > It work but it permit pid 1 process to reap child without selinux check. Can
> > we have a better way to handle this problem?
> 
> I never understood why security_task_wait() should deny to reap a child. But
> since it can we probably want some explicit "the whole namespace goes away" check.
> We could use, say, PIDNS_HASH_ADDING but I'd suggest something like a trivial change
> below for now.
> 
> Eric, what do you think?
> 
> Oleg.
> 
> diff --git a/security/security.c b/security/security.c
> index f825304..1330b4e 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -1027,6 +1027,9 @@ int security_task_kill(struct task_struct *p, struct siginfo *info,
>  
>  int security_task_wait(struct task_struct *p)
>  {
> +	/* must be the exiting child reaper */
> +	if (unlikely(current->flags & PF_EXITING))
> +		return 0;
>  	return call_int_hook(task_wait, 0, p);
>  }
>  

  reply	other threads:[~2017-01-09 18:29 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <58732BCF.4090908@huawei.com>
     [not found] ` <58734284.1060504@huawei.com>
     [not found]   ` <b7f75f65-592a-5102-0ac5-4d3aa43f0b55@huawei.com>
2017-01-09 10:51     ` SELinux lead to soft lockup when pid 1 proceess reap child yangshukui
2017-01-09 18:12       ` Oleg Nesterov
2017-01-09 18:29         ` Oleg Nesterov [this message]
2017-01-09 18:43           ` Stephen Smalley
2017-01-09 23:49             ` Paul Moore
2017-01-10  0:26             ` Casey Schaufler
2017-03-09  9:03       ` isolate selinux_enforcing yangshukui
2017-03-09  9:03         ` yangshukui
2017-03-09 15:28         ` Stephen Smalley
2017-03-09 15:28           ` Stephen Smalley
2017-03-09 15:39           ` Stephen Smalley
2017-03-09 15:39             ` Stephen Smalley
2017-03-09 16:39         ` Casey Schaufler
2017-03-09 16:39           ` Casey Schaufler
2017-03-09 20:49           ` Eric W. Biederman
2017-03-09 20:49             ` Eric W. Biederman
2017-03-10  0:05             ` Paul Moore
2017-03-10  0:05               ` Paul Moore
2017-03-13  7:06             ` James Morris
2017-03-13  7:06               ` James Morris
2017-03-13 16:05               ` Casey Schaufler
2017-03-13 16:05                 ` Casey Schaufler

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=20170109182915.GC8972@redhat.com \
    --to=oleg@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=eparis@parisplace.org \
    --cc=guohanjun@huawei.com \
    --cc=h.huangqiang@huawei.com \
    --cc=james.l.morris@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=miaoxie@huawei.com \
    --cc=paul@paul-moore.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    --cc=serge.hallyn@ubuntu.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=yangshukui@huawei.com \
    --cc=zhangdianfang@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.