Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751954AbaG0MIf (ORCPT ); Sun, 27 Jul 2014 08:08:35 -0400 Received: from mail-vc0-f172.google.com ([209.85.220.172]:40133 "EHLO mail-vc0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751788AbaG0MIc (ORCPT ); Sun, 27 Jul 2014 08:08:32 -0400 MIME-Version: 1.0 In-Reply-To: References: <1406296033-32693-1-git-send-email-drysdale@google.com> <1406296033-32693-11-git-send-email-drysdale@google.com> <53D26355.9020809@redhat.com> From: David Drysdale Date: Sun, 27 Jul 2014 13:08:11 +0100 Message-ID: Subject: Re: [PATCH 10/11] capsicum: prctl(2) to force use of O_BENEATH To: Andy Lutomirski Cc: Paolo Bonzini , Al Viro , LSM List , Greg Kroah-Hartman , Paul Moore , James Morris , Kees Cook , Linux API , Meredydd Luff , Christoph Hellwig , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 25, 2014 at 5:00 PM, Andy Lutomirski wrote: > > On Jul 25, 2014 7:02 AM, "Paolo Bonzini" wrote: > > > > Il 25/07/2014 15:47, David Drysdale ha scritto: > > > @@ -1996,6 +2013,17 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3, > > > if (arg2 || arg3 || arg4 || arg5) > > > return -EINVAL; > > > return current->no_new_privs ? 1 : 0; > > > + case PR_SET_OPENAT_BENEATH: > > > + if (arg2 != 1 || arg4 || arg5) > > > + return -EINVAL; > > > + if ((arg3 & ~(PR_SET_OPENAT_BENEATH_TSYNC)) != 0) > > > + return -EINVAL; > > > + error = prctl_set_openat_beneath(me, arg3); > > > + break; > > > + case PR_GET_OPENAT_BENEATH: > > > + if (arg2 || arg3 || arg4 || arg5) > > > + return -EINVAL; > > > + return me->openat_beneath; > > > case PR_GET_THP_DISABLE: > > > if (arg2 || arg3 || arg4 || arg5) > > > return -EINVAL; > > > > > > > Why are you always forbidding a change of prctl from 1 to 0? It should > > be safe if current->no_new_privs is clear. > > I don't immediately see why you're forbidding unsettling it at all. > If you need it to be sticky, then use seccomp or Capsicum to make it > sticky. Good point, that would make the function more generic -- needing to latch is specific to Capsicum's use of it. > > Also, the way implementation is dangerously racy -- if anyone pokes at > adjacent bitfields without the lock, they can get corrupted. Try > basing on Kees' seccomp tree or security-next and using the new atomic > flags field. Ah yes, sorry -- I hadn't yet shifted the implementation to line up with the work you and Kees have put into the seccomp stuff. > > > --Andy > > > > > Do new threads inherit from the parent? > > > > Also, I wonder if you need something like this check: > > > > /* > > * Installing a seccomp filter requires that the task has > > * CAP_SYS_ADMIN in its namespace or be running with no_new_privs. > > * This avoids scenarios where unprivileged tasks can affect the > > * behavior of privileged children. > > */ > > if (!current->no_new_privs && > > security_capable_noaudit(current_cred(), current_user_ns(), > > CAP_SYS_ADMIN) != 0) > > return -EACCES; > > > > Paolo Yes, new threads inherit the flag from the parent so the NNP||CAP_SYS_ADMIN check is probably needed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/