On Tue, 2016-07-19 at 16:38 +0000, Linda Arens wrote: > Hi Ben and Debian Kernel team. > > Thank you for this information. I provided it to our team and we > have an additional question and want to clarify what we see. > > 1. Could you please let us know when these changes/features will > be added and in what branches? Already done in experimental and will be enabled in unstable with the first upload based on Linux 4.7. > 2. you mention the following: > …it still looks prone to deadlocks and it doesn't really > prevent reading malware. > So I'll enable this but log a warning when it's used because > it's not a > feature I really want to support. > > KL: We have found that it is possible to create deadlocks using > fanotify and even crash the whole operation system from the user > space, the root cause of this is fanotify itself that is able to > intercept file operations, not the fanotify access permission. There's a big difference between implementation bugs, which can generally be fixed, and flaws in an API design, which cannot. > Since fanotify is already enabled in the Debian kernel we are > not adding risks for the end-users by enabling the access permission > feature in the kernel. Therefore we are not sure why a warning would > be given for enabling the access permission feature. fanotify permission checking causes arbitrary tasks to block waiting for the checker, which can easily include tasks that the checker depends on to make its decision. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once.
Attachment:
signature.asc
Description: This is a digitally signed message part