[PATCH 1/1] Fanotify: Introduce a permissive mode

[Jan Kara]

On Tue 15-08-17 12:19:50, Amir Goldstein wrote:
> On Mon, Aug 14, 2017 at 5:04 PM, Steve Grubb <sgrubb at redhat.com> 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.

Agreed. You need CAP_SYS_ADMIN to be able to set up watches for access
control. If you have applications with CAP_SYS_ADMIN you don't trust, just
don't run them or fix bugs in them. Kernel parameter is not the right way
to fix broken applications with administrative priviledges.

> I hope I am not out of line to propose:
> 
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> 
>  FANOTIFY
> -M:     Eric Paris <eparis at redhat.com>
> +M:     Jan Kara <jack at suse.com>
> +R:     Amir Goldstein <amir73il at gmail.com>
> +L:     linux-fsdevel at vger.kernel.org
>  S:     Maintained
>  F:     fs/notify/fanotify/
>  F:     include/linux/fanotify.h

Yeah, I'll queue it up and the same for inotify & dnotify.

								Honza
-- 
Jan Kara <jack at suse.com>
SUSE Labs, CR