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

[Steve Grubb]

On Tuesday, August 15, 2017 6:19:50 AM EDT 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

Agreed, but sometimes you have to. If you are tinkering with application 
whitelisting policy and make a mistake, you just locked yourself out of the 
system or it fails booting. So, my suggested uses for this is system recovery 
and policy debugging. Hopefully the first is more clear. Let me explain the 
second one a bit.

To debug policy, I created a soft-permissive mode by asking for watches on 
file access without returning a decision. What I found was that there are 
short lived files that something requests access to and hits the queue to the 
daemon. But by the time the daemon looks at the file, it gets an EBADFD or the 
process requesting it is dead and gone. So, I have no idea what the file was 
or what was asking for it.

So, there is some utility to having the application stopped so that the daemon 
can do its checks but then throw away the answer so that more of the policy 
can be verified.


> *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.

I was hoping the audit event was a big enough warning. But something for 
dmesg/syslog is easy to add.


> 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.

Hmm. The access control policy would be targeting the FAN_CLASS_CONTENT, 
though.

-Steve