Received: by 10.192.165.148 with SMTP id m20csp3924103imm; Mon, 7 May 2018 23:10:06 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo6Q7n55d2jsnewlHwNcEUoAaXyBj+S3/kv46aAg5VIhc0KQ+Lerbzn2Q3PBy03er38o4Qn X-Received: by 2002:a63:714d:: with SMTP id b13-v6mr24471727pgn.271.1525759806346; Mon, 07 May 2018 23:10:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525759806; cv=none; d=google.com; s=arc-20160816; b=lIa4VEQ50pPFXIoAlCOyltwqkmfrx7vAjmEcFPlAbIPOfiyQKZnef/seGy3SjCcIyZ /SkRXKi/3sp4Wvho6MLVL87C3JX+zbivB4pdC7NfF61ra18rmQ+NNy8x+1mcZc4ujMjX 7G+vZkywUN9MxGo2SqwS61l61H2RR2QaSuGMTilrF8fkpG89bMx/GICi2LfbwBYCfH0M Q+5eKReXsL/esbVyMiJoPP+tSaFTLgrxJs8dyGLtVaGwTxdKpY1NRF1SehKkk7JI32Ue 1bd0I6y1KPXY6/YC+0loErQ3ONGv1zVxCJyWPlZ6+YHrCbzhq8ftRmbYqnSvsj+6EcJI qzJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=+4CWQNlIerEJVg4Oghz1CSYPfG4pBIF1JrT3zi3jIQg=; b=jC1JPwdsjMKrkhj7SIy6ZjFjE5pyMZKxGNAWzL0XAWE/CIcMX8oXQZ0KDSEBmWgQXs AdIgd0h5SNguHYIFYhPpJqzP0Zq6lJwkErXmLTspaqVQUSGoSW6hYOBnrnxRMf0oCSgl dRSG0Yk9eqTwX5pHLOO94tOeclJRpnrXDGdCO/eCbp2KwKI82xRNSsS8Ks/9nb0gzlCl 5qtcm5T+aAkc8AxcHaiJuGp5HPjaaOY+5NGD8hj7alWhv7RtGOObzvp3Xp7zKLF5JncU CGLn0TtV/+GcF9i8KtBfoCXS+V+XFiP++GuM7x+0ytbjP4fk1gu/vuEai847QZ/MErbi 3YFw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=1Y4xoVL6; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p15-v6si4313450pgf.287.2018.05.07.23.09.51; Mon, 07 May 2018 23:10:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=1Y4xoVL6; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754135AbeEHGJk (ORCPT + 99 others); Tue, 8 May 2018 02:09:40 -0400 Received: from mail-lf0-f48.google.com ([209.85.215.48]:45218 "EHLO mail-lf0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754000AbeEHGJg (ORCPT ); Tue, 8 May 2018 02:09:36 -0400 Received: by mail-lf0-f48.google.com with SMTP id y14-v6so43712592lfy.12 for ; Mon, 07 May 2018 23:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+4CWQNlIerEJVg4Oghz1CSYPfG4pBIF1JrT3zi3jIQg=; b=1Y4xoVL6ZL+YQdnhpFxf8gYaQEiSrTRG9rfc+Y7AtSmcJ1d+SrgnbovjQAaHnoSWQH hXv0k/OoXG0SmjuclU2rqnuyiYeIxmcsF/qLSXCcoZM296gGAgSFRHrXTU1eCKNcMG9s 3fpKZafd9JBKItrQvJr6Hc3MSNRLs6EKpg0uu8eds+9BpfSVUPxd66E/4ly7XZnESffA 9Uf4d1cIiFHPrEyDltQtOBhiCpKCWwUrUACf1bzUf8sOazCxXjyTuO50ovfC/lGKVwAE otoYlyAEr+x88oAW2ZB78d65BlJ31h82ytJ9k5Mb+1u9BxbYad1yR874PEtAv7pOtthM HJ7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+4CWQNlIerEJVg4Oghz1CSYPfG4pBIF1JrT3zi3jIQg=; b=VSiGWOHUyxbTTq9LS/7OgtpUxdEf3Tlx6dBuIyEjKc7AhNR9KJ7M484Eqj19nNCawi A/lzowo1sej0sNy3/q2J5VpgBWoHmor1naOksRQQ8cYel8YPhgMGBBxvxdjpygUdBCGX T3J7LouqV15FKsycilPt+NS+RSkP3ciGr+YlZAMbQTpYrWnY8LLnEBZzQwUOQF0gjLh3 fElzjNtfpOYt8Zw9JePdnRmQ8/19IcOIoS+cbFaO0lpcPfkZAfsPyZXwRFvzWNPiGjvh KZ7PgsSjKZ7Jd5pKH1HneOwPzF1RPS1XPKKrGsXKrjCDkKO3d/ZK5tcnd7P7lCNl4kx0 KRPw== X-Gm-Message-State: ALKqPwdEjBAA2e8dhqR3kZAkHS4leqOGP2DAt9rPVqv9ILPFpqctTHzs B577saQKI0Lo1JDqOVAR0sdyrPcLXZX+repHt4Ob X-Received: by 2002:a19:10e1:: with SMTP id 94-v6mr4699508lfq.145.1525759774121; Mon, 07 May 2018 23:09:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:a947:0:0:0:0:0 with HTTP; Mon, 7 May 2018 23:09:33 -0700 (PDT) X-Originating-IP: [172.3.143.147] In-Reply-To: References: <1525396095-27737-1-git-send-email-tyhicks@canonical.com> From: Paul Moore Date: Tue, 8 May 2018 02:09:33 -0400 Message-ID: Subject: Re: [PATCH v3 0/4] Better integrate seccomp logging and auditing To: Kees Cook , Tyler Hicks Cc: LKML , Andy Lutomirski , Will Drewry , Eric Paris , Steve Grubb , Jonathan Corbet , Linux Audit , linux-security-module , linux-doc@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 6, 2018 at 7:36 PM, Kees Cook wrote: > On Sun, May 6, 2018 at 2:31 PM, Paul Moore wrote: >> On Thu, May 3, 2018 at 9:08 PM, Tyler Hicks wrote: >>> Seccomp received improved logging controls in v4.14. Applications can opt into >>> logging of "handled" actions (SECCOMP_RET_TRAP, SECCOMP_RET_TRACE, >>> SECCOMP_RET_ERRNO) using the SECCOMP_FILTER_FLAG_LOG bit when loading filters. >>> They can also debug filter matching with the new SECCOMP_RET_LOG action. >>> Administrators can prevent specific actions from being logged using the >>> kernel.seccomp.actions_logged sysctl. >>> >>> However, one corner case intentionally wasn't addressed in those v4.14 changes. >>> When a process is being inspected by the audit subsystem, seccomp's decision >>> making for logging ignores the new controls and unconditionally logs every >>> action taken except for SECCOMP_RET_ALLOW. This isn't particularly useful since >>> many existing applications don't intend to log handled actions due to them >>> occurring very frequently. This amount of logging fills the audit logs without >>> providing many benefits now that application authors have fine grained controls >>> at their disposal. >>> >>> This patch set aligns the seccomp logging behavior for both audited and >>> non-audited processes. It also emits an audit record, if auditing is enabled, >>> when the kernel.seccomp.actions_logged sysctl is written to so that there's a >>> paper trail when entire actions are quieted. >>> >>> Changes in v3: >>> * Patch 3 >>> - Never drop a field when emitting the audit record >>> - Use the value "?" for the actions field when an error occurred while >>> writing to the sysctl >>> - Use the value "?" for the actions and/or old-actions fields when a failure >>> to translate actions to names >>> - Use the value "(none)" for the actions and/or old-actions fields when no >>> actions are specified >>> + This is possible when writing an empty string to the sysctl >>> - Update the commit message to note the new values and give an example of >>> when an empty string is written >>> * Patch 4 >>> - Adjust the control flow of seccomp_log() to exit early if nothing should be >>> logged >>> >>> Changes in v2: >>> * Patch 2 >>> - New patch, allowing for a configurable separator between action names >>> * Patch 3 >>> - The value of the actions field in the audit record now uses a comma instead >>> of a space >>> - The value of the actions field in the audit record is no longer enclosed in >>> quotes >>> - audit_log_start() is called with the current processes' audit_context in >>> audit_seccomp_actions_logged() >>> - audit_seccomp_actions_logged() no longer records the pid, uid, auid, tty, >>> ses, task context, comm, or executable path >>> - The new and old value of seccomp_actions_logged is recorded in the >>> AUDIT_CONFIG_CHANGE record >>> - The value of the "res" field in the CONFIG_CHANGE audit record is corrected >>> (1 indicates success, 0 failure) >>> - Updated patch 3's commit message to reflect the updated audit record format >>> in the examples >>> * Patch 4 >>> - A function comment for audit_seccomp() was added to explain, among other >>> things, that event filtering is performed in seccomp_log() >> >> Kees, are you still okay with v3? Also, are you okay with these >> patches going in via the audit tree, or would you prefer to take them >> via seccomp? I've got a slight preference for the audit tree myself, >> but as I said before, as long as it hits Linus' tree I'm happy. > > Yup, it looks good. I have no tree preference, so you win! :) Please > consider the whole series: > > Acked-by: Kees Cook Merged into audit/next, thanks guys. -- paul moore www.paul-moore.com