Re: [PATCH 1/1] Fanotify: Introduce a permissive mode
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(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
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