From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f68.google.com ([209.85.218.68]:36775 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753423AbdHOKTv (ORCPT ); Tue, 15 Aug 2017 06:19:51 -0400 Received: by mail-oi0-f68.google.com with SMTP id b130so380618oii.3 for ; Tue, 15 Aug 2017 03:19:50 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <3663877.NZSPRKlUQW@x2> References: <3663877.NZSPRKlUQW@x2> From: Amir Goldstein Date: Tue, 15 Aug 2017 12:19:50 +0200 Message-ID: Subject: Re: [PATCH 1/1] Fanotify: Introduce a permissive mode To: Steve Grubb Cc: fsdevel , Linux Audit , Jan Kara Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Aug 14, 2017 at 5:04 PM, Steve Grubb wrote: > Hello, > > The fanotify interface can be used as an access control subsystem. If > for some reason the policy is bad, there is potentially no good way to > recover the system. This patch introduces a new command line variable, > fanotify_enforce, to allow overriding the access decision from user > space. The initialization status is recorded as an audit event so that > there is a record of being in permissive mode for the security officer. :-/ overriding the security access decision sounds like a bad practice *if* at all this method is acceptable overriding access decision should probably be accompanied with pr_warn_ratelimited and a big warning for fanotify_init with FAN_CLASS_{,PRE_}CONTENT priority. If the proposed kernel param is acceptable by others, I would prefer that it prevents setting up FAN_CLASS_{,PRE_}CONTENT priority watches, instead of setting them up and ignoring the user daemon response. B.T.W Jan, I hope I am not out of line to propose: --- a/MAINTAINERS +++ b/MAINTAINERS FANOTIFY -M: Eric Paris +M: Jan Kara +R: Amir Goldstein +L: linux-fsdevel@vger.kernel.org S: Maintained F: fs/notify/fanotify/ F: include/linux/fanotify.h