On Tue 15-08-17 12:19:50, Amir Goldstein wrote:
> On Mon, Aug 14, 2017 at 5:04 PM, Steve Grubb <sgrubb@xxxxxxxxxx> 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@xxxxxxxxxx>
> +M: Jan Kara <jack@xxxxxxxx>
> +R: Amir Goldstein <amir73il@xxxxxxxxx>
> +L: linux-fsdevel@xxxxxxxxxxxxxxx
> 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@xxxxxxxx>
SUSE Labs, CR
