Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp751120imu; Fri, 16 Nov 2018 09:35:40 -0800 (PST) X-Google-Smtp-Source: AJdET5evwcWrSykzmPD745uZreH2D4C2Ym1yrSUal3p4NLK49/qz36+rUdRUjvecI0RZUbDDIzuS X-Received: by 2002:a62:6881:: with SMTP id d123-v6mr12437911pfc.195.1542389740366; Fri, 16 Nov 2018 09:35:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542389740; cv=none; d=google.com; s=arc-20160816; b=LmpXzePJvNRojCCIlJvQM3sdWyh2kuH4084oYnrL6haYQ+qdwSnkt2sm+v/jym6lBc z/rZT552f0XyKwqkEk3U/+gHRa4ufDs6WusQWBUzwuTZ1Flo2HXPpR/Z6pHkOAoqoQgy WtezsRbqYBB1eULyq7yhnWhhy5d++r1ThfWxpuxJBC5Xc+KsWxSmn99AevfrZ1m2va/l U+oRBGQna7ev2i+HqNtMOltth81NIZJ6098vpGW34zR9xNuTJLGJrLcrxB9wtd8B9srB A/vLepTQlzbkkGuJEToerx0X83L8UpElRDfZtLO4BOi1YvuqGM9NEPFI9T02lzXDjm63 bR6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:references :in-reply-to:message-id:date:subject:cc:to:from; bh=LtudfTzUpdy0BVk8a5yKDz4yTQG1NYv5sjixBCsJf5M=; b=YKdzAXUJqHN9mWA7bLoIcmsEWwtBU3tUjTJXNJyjYxRhDULyMsviCFc5sxAKaEMN1N OFol//ilKUvs0jbkmy/In6aTyqLf5D0wsjsmC0gOU8beJrJ8VU9Id0Vvu63Nd6xD0VF3 VCu+fUQnHb91qMHc6xbVqaICuyoC51JVOGIK2Y1wpC5k9Z465VvaJfTtuQkw67gNy3g4 Rw7xWkMgsKdgtN+6+i55eH0oh2mC4SDY7rGgJlx4V5tJ0CyncDNnB765JCE4iBw/+LLa YXcnLJ94FVdx08spZ1mZsIib3jDufkFWn8dwaBH5xZ+D9p6hJB+l1I5uC1BZ9jJn6T8b VwCw== 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 4-v6si33483766ple.236.2018.11.16.09.35.25; Fri, 16 Nov 2018 09:35:40 -0800 (PST) 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 S2390191AbeKQDrg (ORCPT + 99 others); Fri, 16 Nov 2018 22:47:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34864 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729140AbeKQDrf (ORCPT ); Fri, 16 Nov 2018 22:47:35 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AD50458E27; Fri, 16 Nov 2018 17:34:18 +0000 (UTC) Received: from madcap2.tricolour.ca (ovpn-112-24.phx2.redhat.com [10.3.112.24]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9A04960E1C; Fri, 16 Nov 2018 17:34:12 +0000 (UTC) From: Richard Guy Briggs To: linux-fsdevel@vger.kernel.org, viro@ZenIV.linux.org.uk, LKML , Linux-Audit Mailing List Cc: Paul Moore , Eric Paris , Steve Grubb , Richard Guy Briggs Subject: [RFC PATCH ghak100 V1 2/2] audit: moar filter PATH records keyed on filesystem magic Date: Fri, 16 Nov 2018 12:33:14 -0500 Message-Id: <208a86c97cd93181ffd7db2e5f95da012ab41a48.1542149969.git.rgb@redhat.com> In-Reply-To: References: In-Reply-To: References: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 16 Nov 2018 17:34:18 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Like 42d5e37654e4 ("audit: filter PATH records keyed on filesystem magic") Any user or remote filesystem could become unavailable and effectively block on a forced unmount. -a always,exit -S umount2 -F key=umount2 Provide a method to ignore these user and remote filesystems to prevent them from being impossible to unmount. Extend the "AUDIT_FILTER_FS" filter that uses the field type AUDIT_FSTYPE keying off the filesystem 4-octet hexadecimal magic identifier to filter specific filesystems to cover audit_inode() to address this blockage. An example rule would look like: -a never,filesystem -F fstype=0x517B -F key=ignore_smb -a never,filesystem -F fstype=0x6969 -F key=ignore_nfs Arguably the better way to address this issue is to disable auditing processes that touch removable filesystems. Please see the github issue tracker https://github.com/linux-audit/audit-kernel/issues/100 Signed-off-by: Richard Guy Briggs --- kernel/auditsc.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/kernel/auditsc.c b/kernel/auditsc.c index d39a7fbaf944..59d6d3fbc00e 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -1777,10 +1777,33 @@ void __audit_inode(struct filename *name, const struct dentry *dentry, struct inode *inode = d_backing_inode(dentry); struct audit_names *n; bool parent = flags & AUDIT_INODE_PARENT; + struct audit_entry *e; + struct list_head *list = &audit_filter_list[AUDIT_FILTER_FS]; + int i; if (!context->in_syscall) return; + rcu_read_lock(); + if (!list_empty(list)) { + list_for_each_entry_rcu(e, list, list) { + for (i = 0; i < e->rule.field_count; i++) { + struct audit_field *f = &e->rule.fields[i]; + + if (f->type == AUDIT_FSTYPE) { + if (audit_comparator(inode->i_sb->s_magic, + f->op, f->val)) { + if (e->rule.action == AUDIT_NEVER) { + rcu_read_unlock(); + return; + } + } + } + } + } + } + rcu_read_unlock(); + if (!name) goto out_alloc; -- 1.8.3.1