From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423104AbdAISu1 (ORCPT ); Mon, 9 Jan 2017 13:50:27 -0500 Received: from emsm-gh1-uea11.nsa.gov ([8.44.101.9]:21795 "EHLO emsm-gh1-uea11.nsa.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965371AbdAISuY (ORCPT ); Mon, 9 Jan 2017 13:50:24 -0500 X-Greylist: delayed 591 seconds by postgrey-1.27 at vger.kernel.org; Mon, 09 Jan 2017 13:50:24 EST X-IronPort-AV: E=Sophos;i="5.33,340,1477958400"; d="scan'208";a="2132616" IronPort-PHdr: =?us-ascii?q?9a23=3AITPaaBGJ62IdFS0XUPk28p1GYnF86YWxBRYc798d?= =?us-ascii?q?s5kLTJ76ocWybnLW6fgltlLVR4KTs6sC0LuK9fq8EjVZvd6oizMrSNR0TRgLiM?= =?us-ascii?q?EbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ/iOgVr?= =?us-ascii?q?O+/7BpDdj9it1+C15pbffxhEiCCzbL52Ixi6txvdu8YZjYd/N6o8xQbCr2dVde?= =?us-ascii?q?hR2W5mP0+YkQzm5se38p5j8iBQtOwk+sVdT6j0fLk2QKJBAjg+PG87+MPktR/Y?= =?us-ascii?q?TQuS/XQcSXkZkgBJAwfe8h73WIr6vzbguep83CmaOtD2TawxVD+/4apnVAPkhS?= =?us-ascii?q?EaPDMi7mrZltJ/g75aoBK5phxw3YjUYJ2ONPFjeq/RZM4WSXZdUspUUSFODJm8?= =?us-ascii?q?b48SBOQfO+hWoZT2q18XoRegGQWgAeXiwSJKiHDrx603y+cvHxzG0gI+EdwBsn?= =?us-ascii?q?rUrNLpO6kVXu+7w7LFzSnAYv5MxTvw8pTEfxInrPqRXbxwa83RyUw3Gg3YklWf?= =?us-ascii?q?t5TlPzOL2eQLrmOV8u9gWviri24jtQ5woiWky8A3iobUnYIY0UzE9CVlz4Y1It?= =?us-ascii?q?20Ukh7YcW+H5dKuCGaMJV2T9okTmp1uyg60qULtYO0cSUF0pgqxwPTZ+aZf4WH?= =?us-ascii?q?/B7vTvudLDFlj3x/Yr2/nQy98U24x+35Ucm7zUhFozJektnJqnANzxvT6tWbSv?= =?us-ascii?q?dl/keuxzKP1wfL5+FYO080j6vbK4M6wrIqipoSsVjMHi/xmEnsiq+Zal4k9fSy?= =?us-ascii?q?5+TiY7XmooeQN45yig7gLqQjgtGzDOs3PwQUX2WX5P6w2KPs8EHnWrlGk+U6kq?= =?us-ascii?q?zDv5DbIcQbqLS5AwhQ0os78BawEiym3c8EnXgHMF1FeBWHg5LvO1HVOv/0F/i/?= =?us-ascii?q?g1OykDtz3fDJIqXhAonRLnjEiLrhZqhy61RTyAUt19xf54hbCrUFIPPzXE/8r8?= =?us-ascii?q?HYAQQkMwyy3+bnFc9x2Z8ZWWKKGqWZKr/dsUeU5uIzJOmBfJEaty38K/c7+vHh?= =?us-ascii?q?k2U5mVoGcKim2JsXaWu4Hu9nI0WeZ3rgmMsOEWAPvgAmVuzllEWCUSJPZ3a1R6?= =?us-ascii?q?885Cs0CIe4AofYXIythKaN3CK8Hp1MfGBGC0uMHGzvd4WeQfgDdCaSLdF7njMY?= =?us-ascii?q?UrihTpcr1Quyuw/i17pnMu3U9zUGupL7ztd1/ezTlQop+DxsFcudyWCNT3psnm?= =?us-ascii?q?MMXTA5wL5wrVZ6yleZ3qhym+ZYGsBL5/NVTgc6MobRz/RgBNDvXgLMZc+JR0y7?= =?us-ascii?q?QtWiGD0xS9Uxw9gUY0ljAdmtkhfD3y+yCb8Pi7OLHIA08r7b33XpJsd9y2zJ1K?= =?us-ascii?q?8uj1Y7Q8tAL2umhqBl+AjVCI7EiEWZl7uweqUSwiHN9X2PwnaJvEFdSARwS7nK?= =?us-ascii?q?XWgDZkvKqtT0/kbCT760BrQgPQpByNCNJ7BKat30l1pHSunsONXEb22tnGewAA?= =?us-ascii?q?6CxqmQY4ryZ2UdwCLdBVAAkwAS/HeJKwY+CT2no2/FDDxuCEjgYk3y/ul/sn+0?= =?us-ascii?q?Ukg0zwSSZU17y7W14gIVheCbS/4L3rIIoichqyhuE1a70NLWEtuAqBBnfKVTet?= =?us-ascii?q?494EpH2njXtgNjP5ysNbxthlkbcw5vpUPhyw13CplckcgttH4qwxdyKaWY0Fxb?= =?us-ascii?q?cTOY343wOrvMJ2ny4RCgcaDX1U/f0NqM5qgP7/E4oU35vA61Dkoi72ln095N3n?= =?us-ascii?q?qS/JrKCgUSUZHvXUY56Rd6ob7abjMz5ozO031sPrK5sj/f290zCuoq1Begc81D?= =?us-ascii?q?P6ODEQ/4C9caCNS2KOw2h1ipaQoJPORT9K4yIsOneOKK2K21M+Z6mjKpk2BH7Z?= =?us-ascii?q?tj0kKD6SV8UPTE35UbzPGC2AuISTP8gE2mssDtloBOfSsSEXanySj4GI5RYbV/?= =?us-ascii?q?fYIKCWeoPs22ycxyh4XzVHFE6V6jHVIG2NOpeBaLalz92hBf1VkToXO5gia40T?= =?us-ascii?q?N0nC8zrqaF3yzB3f7idBwZNW5PXmViik3sIYeshdAAQEeodxQplAei5Uvix6lU?= =?us-ascii?q?vqJ/L2bIQUdIYij2LHxiUqqru7qCfs5A8p0pvjtWUOimfV+aTbv9qQMA0yz/B2?= =?us-ascii?q?te2Cw7dzayt5X+mxx1lm2dIW1prHXHZM5wxQ3Q5MDGSfFN2ToGQXowtT6CIVyx?= =?us-ascii?q?MJGP8M6Imo3ErKjqUGasWbVJfCXrxJ/Gvyy+sykiEBS5kOuzh976EEBuwCb92M?= =?us-ascii?q?JqSCbVrT78f4D02qX8OuViKBpGHlj5vvFmF5l+n414v5QZ3XwXl93B5nYcuXvi?= =?us-ascii?q?OtVcn6TlZTwCQiBdkI2d2xTsxEA2diHB/In+THjIh5I7P9Q=3D?= X-IPAS-Result: =?us-ascii?q?A2EIBACj2HNY/wHyM5BdGgEBAQECAQEBAQgBAQEBFQEBAQE?= =?us-ascii?q?CAQEBAQgBAQEBgw8BAQEBAR+FOpsMBoEclzGGIgKBZ1MBAQEBAQEBAQIBAmAog?= =?us-ascii?q?jMaAYIaAQEBAQIBIwQLAUYQCQINCwICJgICVwYBiHUFCJJAnU6BazomAol0AQE?= =?us-ascii?q?BAQEBBAEBAQEBAQEhgQuEdoUlh06CXgWQEYsLkU2Bd4UIgz+GHpJVWIEMBgIQB?= =?us-ascii?q?xsPhGccgX0giRsBAQE?= Message-ID: <1483987383.20858.84.camel@tycho.nsa.gov> Subject: Re: SELinux lead to soft lockup when pid 1 proceess reap child From: Stephen Smalley To: Oleg Nesterov , yangshukui Cc: selinux@tycho.nsa.gov, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Kefeng Wang , "Guohanjun (Hanjun Guo)" , "'Qiang Huang'" , Lizefan , "miaoxie (A)" , Zhangdianfang , paul@paul-moore.com, eparis@parisplace.org, james.l.morris@oracle.com, ebiederm@xmission.com, serge.hallyn@ubuntu.com Date: Mon, 09 Jan 2017 13:43:03 -0500 In-Reply-To: <20170109182915.GC8972@redhat.com> References: <58732BCF.4090908@huawei.com> <58734284.1060504@huawei.com> <58736B2E.90201@huawei.com> <20170109181225.GB8972@redhat.com> <20170109182915.GC8972@redhat.com> Organization: National Security Agency Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2017-01-09 at 19:29 +0100, Oleg Nesterov wrote: > Seriously, could someone explain why do we need the > security_task_wait() > hook at all? I would be ok with killing it. IIRC, the original motivation was to block an unauthorized data flow from child to parent when the child context differs, but part of that original design was also to reparent the child automatically, and that was never implemented.  I don't think there is a real use case for it in practice and it just breaks things, so let's get rid of it unless someone objects. > > > 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); > >  } > >