Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752088AbbFBT2Q (ORCPT ); Tue, 2 Jun 2015 15:28:16 -0400 Received: from mail-lb0-f178.google.com ([209.85.217.178]:32881 "EHLO mail-lb0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751864AbbFBT2E (ORCPT ); Tue, 2 Jun 2015 15:28:04 -0400 MIME-Version: 1.0 In-Reply-To: <556DFDB2.3050205@parallels.com> References: <1433186918-9626-1-git-send-email-tycho.andersen@canonical.com> <20150602182829.GA23449@redhat.com> <556DFDB2.3050205@parallels.com> From: Andy Lutomirski Date: Tue, 2 Jun 2015 12:27:42 -0700 Message-ID: Subject: Re: [PATCH] seccomp: add ptrace commands for suspend/resume To: Pavel Emelyanov Cc: Oleg Nesterov , Tycho Andersen , "linux-kernel@vger.kernel.org" , Linux API , Kees Cook , Will Drewry , Roland McGrath , "Serge E. Hallyn" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1579 Lines: 40 On Tue, Jun 2, 2015 at 12:02 PM, Pavel Emelyanov wrote: > >>> +int suspend_seccomp(struct task_struct *task) >>> +{ >>> + int ret = -EACCES; >>> + >>> + spin_lock_irq(&task->sighand->siglock); >>> + >>> + if (!capable(CAP_SYS_ADMIN)) >>> + goto out; >> >> I am puzzled ;) Why do we need ->siglock? And even if we need it, why >> we can't check CAP_SYS_ADMIN lockless? >> >> And I am not sure I understand why do we need the additional security >> check, but I leave this to you and Andy. >> >> If you have the rights to trace this task, then you can do anything >> the tracee could do without the filtering. > > I think _this_ check is required, otherwise the seccomp-ed task (in > filtered mode) fork-s a child, then this child ptrace-attach to parent > (allowed) then suspend its seccomd. And -- we have unpriviledged process > de-seccomped. The interaction between ptrace and seccomp is already highly screwy, and seccomp users can often escape using ptrace. That being said, I'd rather not further enshrine it. It might be worth changing the check to verify that the task trying to suspect seccomp isn't itself subject to seccomp. That should get most of the safety. We are already kind of screwed if someone tries to run criu under seccomp due to unresolved nesting issues. --Andy -- 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/