lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 03 Aug 2018 12:15:16 +0200 From: Jürg Billeter <j@...ron.ch> To: Oleg Nesterov <oleg@...hat.com> Cc: Andrew Morton <akpm@...ux-foundation.org>, Thomas Gleixner <tglx@...utronix.de>, Eric Biederman <ebiederm@...ssion.com>, linux-api@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH v2] prctl: add PR_[GS]ET_KILLABLE On Wed, 2018-08-01 at 16:19 +0200, Oleg Nesterov wrote: > On 07/31, Jürg Billeter wrote: > > > > > Could you explain your use-case? Why a shell wants to use > > > CLONE_NEWPID? > > > > To guarantee that there won't be any runaway processes, i.e., ensure > > that no descendants (background helper daemons or misbehaving > > processes) survive when the child process is terminated. > > We already have PR_SET_CHILD_SUBREAPER. > > Perhaps we can finally add PR_KILL_MY_DESCENDANTS_ON_EXIT? This was already > discussed some time ago, but I can't find the previous discussion... Simple > to implement. This would definitely be an option. You mentioned it last October in the PR_SET_PDEATHSIG_PROC discussion¹. However, as PID namespaces already exist and appear to be a good fit for the most part, I think it makes sense to just add the missing pieces to PID namespaces instead of duplicating part of the PID namespace functionality. Also, based on Eric's comment in that other discussion about no_new_privs not being allowed to increase the attack surface, PR_KILL_MY_DESCENDANTS_ON_EXIT might require CAP_SYS_ADMIN as well (due to setuid children). In which case the only potential benefit would be that it still allows the child to kill arbitrary processes, as far as I can tell. > > And to prevent children from killing their ancestors. > > OK, this is the only reason for CLONE_NEWPID which I can understand so far. > Not that I understand why this is that useful ;) The overall goal is increasing isolation between (some) child processes and the rest of the system. Isolation from runaway processes and isolation from signals are independent aspects and it could be useful to control them independently. However, I also expect it to be common that both are wanted at the same time. Jürg ¹ https://lkml.org/lkml/2017/10/5/546
Powered by blists - more mailing lists