On Tue, Aug 15, 2017 at 4:44 PM, Steve Grubb <sgrubb@xxxxxxxxxx> wrote:
> 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@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
>
> 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.
>
So for first use case, my suggestion to prevent setting up high priority
watches should be sufficient to stop the offending daemon from running. Right?
> 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.
>
No warning is big enough if the change breaks existing apps behavior.
One of the major flaws in your suggestion is that it changes the behavior
globally. I think what you want for the debugging use case is to introduce
a new fanotify_init() flag FAN_PERMISSIVE.
Your daemon could set the new flag to opt-in for the new behavior, which
may depend on kernel parameter, or even on sysfs knob if you like.
>
>> 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.
>
Yeh, well, that's only the solution for the first use case.
Amir.
