From patchwork Thu Jun 18 13:48:22 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adrian Reber X-Patchwork-Id: 11612211 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 7918B913 for ; Thu, 18 Jun 2020 13:49:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6188A20885 for ; Thu, 18 Jun 2020 13:49:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Bg3ggKRi" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730294AbgFRNtP (ORCPT ); Thu, 18 Jun 2020 09:49:15 -0400 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:36134 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727101AbgFRNtM (ORCPT ); Thu, 18 Jun 2020 09:49:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592488150; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=DUQ6ngZQh7gXiB43u6OrO1UGnUYbS+2l9T1n8YlMUQ0=; b=Bg3ggKRiV+OZjlHh+lAi/3B9cwr8r4OJU/xXQkZFBqkG6w/A1t6GrFD/TI997CPFZRey9n /oYoAXGStHfb+oR9AaVB7q20hOfQVxJop4X7YmJJTm92p7+wU7CTzMewsnoO7ybuPCZm/P ptyVgF4PVN8bKaXKeO/MTxe3Co8RI1g= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-230-929ZvOwgOPOcHf0IkOhyBg-1; Thu, 18 Jun 2020 09:49:09 -0400 X-MC-Unique: 929ZvOwgOPOcHf0IkOhyBg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2AD08107ACF4; Thu, 18 Jun 2020 13:49:05 +0000 (UTC) Received: from dcbz.redhat.com (ovpn-112-197.ams2.redhat.com [10.36.112.197]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6837D1E2264; Thu, 18 Jun 2020 13:48:51 +0000 (UTC) From: Adrian Reber To: Christian Brauner , Eric Biederman , Pavel Emelyanov , Oleg Nesterov , Dmitry Safonov <0x7f454c46@gmail.com>, Andrei Vagin , Nicolas Viennot , =?utf-8?b?TWljaGHFgiBDxYJh?= =?utf-8?b?cGnFhHNraQ==?= , Kamil Yurtsever , Dirk Petersen , Christine Flood , Casey Schaufler Cc: Mike Rapoport , Radostin Stoyanov , Adrian Reber , Cyrill Gorcunov , Serge Hallyn , Stephen Smalley , Sargun Dhillon , Arnd Bergmann , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, selinux@vger.kernel.org, Eric Paris , Jann Horn , linux-fsdevel@vger.kernel.org Subject: [PATCH v3 0/3] capabilities: Introduce CAP_CHECKPOINT_RESTORE Date: Thu, 18 Jun 2020 15:48:22 +0200 Message-Id: <20200618134825.487467-1-areber@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: This is v3 of the 'Introduce CAP_CHECKPOINT_RESTORE' patchset. There is only one change from v2: * made if condition easier to read as requested by Cyrill Besides that there were no further comments on the changes proposed in this patchset. There was the discussion from Andrei that PTRACE_O_SUSPEND_SECCOMP is also needed for checkpointing. CRIU already has the possibility to detect if a process is using seccomp and could so tell the user that it cannot checkpoint a process if the process is using seccomp. As seccomp has not come up in the requests from users to use CRIU as non-root so far and as there was some push back from Christian to allow PTRACE_O_SUSPEND_SECCOMP if CAP_CHECKPOINT_RESTORE is set I would like to leave this open for the future. Another discussion was around relaxing the existing map_files check from capable() to ns_capable() or even completely removing it. Even if this happens we still need CAP_CHECKPOINT_RESTORE and the removal or change to ns_capable() is not blocked by this patchset. Besides that there was nothing speaking against CAP_CHECKPOINT_RESTORE during the v2 discussions. Adrian Reber (2): capabilities: Introduce CAP_CHECKPOINT_RESTORE selftests: add clone3() CAP_CHECKPOINT_RESTORE test Nicolas Viennot (1): prctl: Allow ptrace capable processes to change exe_fd fs/proc/base.c | 8 +- include/linux/capability.h | 6 + include/uapi/linux/capability.h | 9 +- kernel/pid.c | 2 +- kernel/pid_namespace.c | 2 +- kernel/sys.c | 21 +- security/selinux/include/classmap.h | 5 +- tools/testing/selftests/clone3/Makefile | 4 +- .../clone3/clone3_cap_checkpoint_restore.c | 203 ++++++++++++++++++ 9 files changed, 245 insertions(+), 15 deletions(-) create mode 100644 tools/testing/selftests/clone3/clone3_cap_checkpoint_restore.c base-commit: 5fcb9628fd1227a5f11d87171cb1b8b5c414d9d9