Re: [PATCH 1/1] Fanotify: Introduce a permissive mode
On Tue 15-08-17 12:19:50, Amir Goldstein wrote:
On Mon, Aug 14, 2017 at 5:04 PM, Steve Grubb
<sgrubb(a)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(a)redhat.com>
+M: Jan Kara <jack(a)suse.com>
+R: Amir Goldstein <amir73il(a)gmail.com>
+L: linux-fsdevel(a)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(a)suse.com>
SUSE Labs, CR