Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S968952AbdD0Xm6 (ORCPT ); Thu, 27 Apr 2017 19:42:58 -0400 Received: from mail-io0-f169.google.com ([209.85.223.169]:33823 "EHLO mail-io0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965358AbdD0Xmu (ORCPT ); Thu, 27 Apr 2017 19:42:50 -0400 MIME-Version: 1.0 In-Reply-To: <0b1a2337-7006-e7cb-f519-dec389ede041@canonical.com> References: <1487043928-5982-1-git-send-email-tyhicks@canonical.com> <0b1a2337-7006-e7cb-f519-dec389ede041@canonical.com> From: Kees Cook Date: Thu, 27 Apr 2017 16:42:48 -0700 X-Google-Sender-Auth: zRWuTCTQNHB-E1Sxao1Vje8wi_M Message-ID: Subject: Re: [PATCH v3 0/4] Improved seccomp logging To: Tyler Hicks Cc: Andy Lutomirski , Paul Moore , Eric Paris , Will Drewry , linux-audit@redhat.com, "linux-kernel@vger.kernel.org" , John Crispin , Linux API 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: 1655 Lines: 40 On Thu, Apr 27, 2017 at 3:17 PM, Tyler Hicks wrote: > Quick update... I finished the move from the high-water mark > log_max_action sysctl to the bitmask based actions_logged sysctl. Awesome! > Unfortunately, I've just realized that SECCOMP_SET_LOGGING, or any > process-wide logging configuration mechanism, will not work. It is fine > for the situation where two unrelated processes set up seccomp filters > that should be logged differently. However, it fails when two closely > related processes, such as parent and child, need to set up seccomp > filters that should be logged differently. Imagine a launcher that sets > up an application sandbox (including a seccomp filter) and then launches > an electron app which will have its own seccomp filter for sandboxing > untrusted code that it runs. Unless the launcher and app completely > agree on actions that should be logged, the logging won't work as > intended for both processes. Oh, you mean the forked process sets up the logging it wants for the filters it just installed, then after exec a process sets up new logging requirements? > I think this needs to be configured at the filter level. I'm not sure that's even the right way to compose the logging desires. So, my initial thought was "whatever ran SECCOMP_SET_LOGGING knows what it's doing" and it should be the actual value. If the launcher wants logs of everything the application does with its filters, then a purely-tied-to-filter approach won't work either. Perhaps log bits can only be enabled? I.e. SECCOMP_SET_LOGGING performs an OR instead of an assignment? -Kees -- Kees Cook Pixel Security