aboutsummaryrefslogtreecommitdiffstats
path: root/fs/notify/fanotify
diff options
context:
space:
mode:
authorEric Paris <eparis@redhat.com>2010-10-28 17:21:57 -0400
committerEric Paris <eparis@redhat.com>2010-10-28 17:22:14 -0400
commit5322a59f14e4cae5f878b9c0c5612d403c230d7f (patch)
tree5090861d8e7df0b69f342c527390007e8c3f68e9 /fs/notify/fanotify
parentbbf2aba50f6ed7c8dd53623fa1437b539928ac39 (diff)
fanotify: ignore fanotify ignore marks if open writers
fanotify will clear ignore marks if a task changes the contents of an inode. The problem is with the races around when userspace finishes checking a file and when that result is actually attached to the inode. This race was described as such: Consider the following scenario with hostile processes A and B, and victim process C: 1. Process A opens new file for writing. File check request is generated. 2. File check is performed in userspace. Check result is "file has no malware". 3. The "permit" response is delivered to kernel space. 4. File ignored mark set. 5. Process A writes dummy bytes to the file. File ignored flags are cleared. 6. Process B opens the same file for reading. File check request is generated. 7. File check is performed in userspace. Check result is "file has no malware". 8. Process A writes malware bytes to the file. There is no cached response yet. 9. The "permit" response is delivered to kernel space and is cached in fanotify. 10. File ignored mark set. 11. Now any process C will be permitted to open the malware file. There is a race between steps 8 and 10 While fanotify makes no strong guarantees about systems with hostile processes there is no reason we cannot harden against this race. We do that by simply ignoring any ignore marks if the inode has open writers (aka i_writecount > 0). (We actually do not ignore ignore marks if the FAN_MARK_SURV_MODIFY flag is set) Reported-by: Vasily Novikov <vasily.novikov@kaspersky.com> Signed-off-by: Eric Paris <eparis@redhat.com>
Diffstat (limited to 'fs/notify/fanotify')
-rw-r--r--fs/notify/fanotify/fanotify_user.c10
1 files changed, 10 insertions, 0 deletions
diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index 1c09e6321c5e..b265936e92d6 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -610,6 +610,16 @@ static int fanotify_add_inode_mark(struct fsnotify_group *group,
610 610
611 pr_debug("%s: group=%p inode=%p\n", __func__, group, inode); 611 pr_debug("%s: group=%p inode=%p\n", __func__, group, inode);
612 612
613 /*
614 * If some other task has this inode open for write we should not add
615 * an ignored mark, unless that ignored mark is supposed to survive
616 * modification changes anyway.
617 */
618 if ((flags & FAN_MARK_IGNORED_MASK) &&
619 !(flags & FAN_MARK_IGNORED_SURV_MODIFY) &&
620 (atomic_read(&inode->i_writecount) > 0))
621 return 0;
622
613 fsn_mark = fsnotify_find_inode_mark(group, inode); 623 fsn_mark = fsnotify_find_inode_mark(group, inode);
614 if (!fsn_mark) { 624 if (!fsn_mark) {
615 int ret; 625 int ret;