Re: [PATCH 1/1] audit: Record fanotify access control decisions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 6, 2017 at 12:18 PM, Jan Kara <jack@xxxxxxx> wrote:
> On Tue 05-09-17 14:32:07, Steve Grubb wrote:
>> The fanotify interface allows user space daemons to make access
>>  control decisions. Under common criteria requirements, we need to
>>  optionally record decisions based on policy. This patch adds a bit mask,
>>  FAN_AUDIT, that a user space daemon can 'or' into the response decision
>>  which will tell the kernel that it made a decision and record it.
>
> [Since this is API change, added linux-api to CC, also added Amir since he
> works with fanotify]
>
> Hum, probably I'm missing something here but why an application responding
> to fanotify event should need to know about audit? Or is it that for CC
> requirements you have to implement some deamon which will arbitrate access
> using fanotify and you need to have decisions logged using kernel audit
> interface?
>
> And another design question: If you need all responses by some daemon
> logged, wouldn't it be more logical to make FAN_AUDIT a property of
> fanotify instance (i.e., a flag to fanotify_init(2))? Or maybe a property
> of fanotify mark (i.e., a flag to fanotify_mark(2))?
>

Even if the use case is auditing blocklisted files, the change of ABI on the
response fd should be opt-in by a new flag to fanotify_init(), something like
FAN_CAN_AUDIT.

In other words, your new daemon that responds with FAN_AUDIT must
fail to start when running on an old kernel that doesn't support the FAN_AUDIT
response, unless it knows how to fall back and call fanotify_init()
again without
FAN_CAN_AUDIT and then not respond with FAN_AUDIT.

Other than that, I agree with Jan that setting FAN_AUDIT by default for
all permission responses at fanotify_init() and maybe fanotify_mark()
sounds useful.
IMO, it makes most sense in proximity to defining the notification class, e.g.:
fanotify_init(FAN_CLASS_CONTENT|FAN_PERM_AUDIT, 0);

Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux