Received: by 10.192.165.148 with SMTP id m20csp30180imm; Thu, 3 May 2018 14:13:52 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrAHDsDRe6e7cf9YoTeASubRuM0kjXpe+nznUNSvEOIa9s8dleRM7VZFZ22mYmetGfZ5dSO X-Received: by 2002:a63:6f4d:: with SMTP id k74-v6mr20687156pgc.112.1525382032508; Thu, 03 May 2018 14:13:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525382032; cv=none; d=google.com; s=arc-20160816; b=IkGDVPW9g1UnP8pMSkRlcF/BU6++vPr3aneyB9iXcBiFTXGeLbme9SkQzfOVGmaY/n PO8w1EHXsfBjtvDqeB/vOUSKtWLtF45vacAcWFkJ6xFwyRA2V3NBZhAYcqgubnyd3SxB g+ZY2+NoB6AKEOou1XAAnAjWtQQFmsS80I88SeO5ZhFDWOEQyaE9/pd+pxk5DpBbUhaj dXMo+0ls+cmFKfhIn/RvLlLT50fq2ekB46fJjmN+aVoCOCbiXLgkv2mqwhjElkmznpzs YqVKdVP9UO9P7wyiw5ozAZ8kzUeJMR1XDnuoHL23zXKmlpZ4b8fS8uwNKLLM3TDex0PP YTsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:organization:message-id:date:subject:cc:to :from:arc-authentication-results; bh=ewnQD2iSuX2TeBVK2gFmnefHLiyk8sos0WOPCjelHb0=; b=Qtxxjt/miRI4CD7JVwUNfMxNDfkroxMfkGnt0QkPphCNDO3aCX9zREsTvdx9nFMMai ijwpzFYFrDrdvZkXsBh+VztRPJioOYSg5Hob2fd5W6DKa5VyNnTVtvcpL7ud2BuUdvdc cU1QudAxmoTH0SNK4boaun3EV3Ha8U0xZky8mHsffEbuALqO+FlpIKoETc076KQuOk2E +BnPquFs6gi30BAFp7VSgNtvXpMAmoIDNO2BwPRm/A1WoY8egfz9Gtuu6h/LSKqNBxRH h+VYw/0K3YKV7pBNf0Tz97y4tnppozVWT/N4WZEQoAkzFMUgiYA31jO21/Z0LiVOVAGX uXpw== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g12si1747373pfm.258.2018.05.03.14.13.38; Thu, 03 May 2018 14:13:52 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751349AbeECVMv (ORCPT + 99 others); Thu, 3 May 2018 17:12:51 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:40574 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751133AbeECVMt (ORCPT ); Thu, 3 May 2018 17:12:49 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4729F81A88BD; Thu, 3 May 2018 21:12:48 +0000 (UTC) Received: from x2.localnet (ovpn-124-126.rdu2.redhat.com [10.10.124.126]) by smtp.corp.redhat.com (Postfix) with ESMTP id B4F1983B75; Thu, 3 May 2018 21:12:45 +0000 (UTC) From: Steve Grubb To: Tyler Hicks Cc: Paul Moore , linux-kernel@vger.kernel.org, Kees Cook , Andy Lutomirski , Will Drewry , Eric Paris , Jonathan Corbet , linux-audit@redhat.com, linux-security-module@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [PATCH v2 3/4] seccomp: Audit attempts to modify the actions_logged sysctl Date: Thu, 03 May 2018 17:12:45 -0400 Message-ID: <2397134.HQDQRr6h1X@x2> Organization: Red Hat In-Reply-To: References: <1525276400-7161-1-git-send-email-tyhicks@canonical.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Thu, 03 May 2018 21:12:48 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Thu, 03 May 2018 21:12:48 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'sgrubb@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, May 3, 2018 4:51:36 PM EDT Tyler Hicks wrote: > On 05/03/2018 03:48 PM, Paul Moore wrote: > > On Thu, May 3, 2018 at 4:42 PM, Steve Grubb wrote: > >> On Thursday, May 3, 2018 4:18:26 PM EDT Paul Moore wrote: > >>> On Wed, May 2, 2018 at 2:18 PM, Steve Grubb wrote: > >>>> On Wednesday, May 2, 2018 11:53:19 AM EDT Tyler Hicks wrote: > >>>>> The decision to log a seccomp action will always be subject to the > >>>>> value of the kernel.seccomp.actions_logged sysctl, even for processes > >>>>> that are being inspected via the audit subsystem, in an upcoming > >>>>> patch. > >>>>> Therefore, we need to emit an audit record on attempts at writing to > >>>>> the > >>>>> actions_logged sysctl when auditing is enabled. > >>>>> > >>>>> This patch updates the write handler for the actions_logged sysctl to > >>>>> emit an audit record on attempts to write to the sysctl. Successful > >>>>> writes to the sysctl will result in a record that includes a > >>>>> normalized > >>>>> list of logged actions in the "actions" field and a "res" field equal > >>>>> to > >>>>> 0. Unsuccessful writes to the sysctl will result in a record that > >>>>> doesn't include the "actions" field and has a "res" field equal to 1. > >>>>> > >>>>> Not all unsuccessful writes to the sysctl are audited. For example, > >>>>> an > >>>>> audit record will not be emitted if an unprivileged process attempts > >>>>> to > >>>>> open the sysctl file for reading since that access control check is > >>>>> not > >>>>> part of the sysctl's write handler. > >>>>> > >>>>> Below are some example audit records when writing various strings to > >>>>> the > >>>>> actions_logged sysctl. > >>>>> > >>>>> Writing "not-a-real-action", when the kernel.seccomp.actions_logged > >>>>> sysctl previously was "kill_process kill_thread trap errno trace > >>>>> log", > >>>>> > >>>>> emits this audit record: > >>>>> type=CONFIG_CHANGE msg=audit(1525275273.537:130): op=seccomp-logging > >>>>> old-actions=kill_process,kill_thread,trap,errno,trace,log res=0 > >>>>> > >>>>> If you then write "kill_process kill_thread errno trace log", this > >>>>> audit > >>>>> > >>>>> record is emitted: > >>>>> type=CONFIG_CHANGE msg=audit(1525275310.208:136): op=seccomp-logging > >>>>> actions=kill_process,kill_thread,errno,trace,log > >>>>> old-actions=kill_process,kill_thread,trap,errno,trace,log res=1 > >>>>> > >>>>> If you then write the string "log log errno trace kill_process > >>>>> kill_thread", which is unordered and contains the log action twice, > >>>>> > >>>>> it results in the same actions value as the previous record: > >>>>> type=CONFIG_CHANGE msg=audit(1525275325.613:142): op=seccomp-logging > >>>>> actions=kill_process,kill_thread,errno,trace,log > >>>>> old-actions=kill_process,kill_thread,errno,trace,log res=1 > >>>>> > >>>>> No audit records are generated when reading the actions_logged > >>>>> sysctl. > >>>> > >>>> ACK for the format of the records. > >>> > >>> I just wanted to clarify the record format with you Steve ... the > >>> "actions" and "old-actions" fields may not be included in the record > >>> in cases where there is an error building the action value string, are > >>> you okay with that or would you prefer the fields to always be > >>> included but with a "?" for the value? > >> > >> A ? would be more in line with how other things are handled. > > > > That's what I thought. > > > > Would you mind putting together a v3 Tyler? :) > > To be clear, "?" is only to be used when the call to > seccomp_names_from_actions_logged() fails, right? Yes and that is a question mark with no quotes in the audit record. > If the sysctl write fails for some other reason, such as when an invalid > action name is specified, can you confirm that you still want *no* > "actions" field, Its best that fields do not disappear. In the case of invalid input, you can just leave the new value as ? so that nothing malicious can be injected into the logs > the "old-actions" field to be the value prior to attempting the update to > the sysctl, and res to be 0? Yes -Steve