fanotify as syscalls
in [Kernel]
|
Prev: BUG kmalloc-64: Poison overwritten, INFO: Allocated in bdi_alloc_work+0x2b/0x100 age=175 cpu=1 pid=3514
Next: [PATCH 62/72] Blackfin: bf537-stamp: add adp5588 gpio resources
From: Andreas Gruenbacher on 21 Sep 2009 17:30 On Monday, 21 September 2009 22:28:23 Jamie Lokier wrote: > It would be logical if fanotify could block and ack those [mount & umount > events] in the same way as it can block and ack other accesses (with the > usual filtering rules on which inodes trigger events, and which don't or are > cached). Hmm. To me, fanotify is about file contents first of all: this is what fanotify wants to be able to veto. Directory events seem reasonable to add for inotify compatibility, but I see no need for access decisions on them. Even less so for mounts and unmounts. (Besides, we can't hold any vfs locks while asking fanotify so those operations wouldn't be atomic, anyway.) Thanks, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jamie Lokier on 21 Sep 2009 18:10 Andreas Gruenbacher wrote: > On Monday, 21 September 2009 22:28:23 Jamie Lokier wrote: > > It would be logical if fanotify could block and ack those [mount & umount > > events] in the same way as it can block and ack other accesses (with the > > usual filtering rules on which inodes trigger events, and which don't or are > > cached). > > Hmm. To me, fanotify is about file contents first of all: this is what > fanotify wants to be able to veto. Surely you don't assume that what constitutes malicious content is independent of it's location and/or name? (See also "echo 'run_virus&' >>.bash_login). Wait a minute. You don't assume that, otherwise why the interest in subtrees? :-) > Directory events seem reasonable to add for inotify compatibility, Did you see may point about userspace caches and how directory events are fundamental to that - there's no way to build a cache without them? > but I see no need for access decisions on them. Please excuse me; I'm a bit confused. Is fanotify intended just for use by access decision programs, or is the plan now for it to also be a replacement for inotify? I'm getting conflicting signals about that. If it's just for access decision programs, and if those aren't going to care about location, then there's no need to add directory events to fanotify at all. But then I'll be demanding subtree support in inotify, please :-) > Even less so for mounts and unmounts. (as root) mkdir foo; mount dodgy foo -oloop; mount --bind foo/cat /bin/cat If fanotify doesn't react to that, which is just a fancy way of saying "zcat virus.gz >/bin/cat" in a way which doesn't cause any writes or opens, what's the point in it? Is fanotify only for checking files written by non-root users? > (Besides, we can't hold any vfs locks > while asking fanotify so those operations wouldn't be atomic, anyway.) Indeed, good point. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Davide Libenzi on 21 Sep 2009 18:20 On Mon, 21 Sep 2009, Jamie Lokier wrote: > I think so to, and that'd be a great all round solution. If this is for anti-malware vendors to intercept userspace accesses they're currently doing it by hacking the syscall table, why don't we offer a way to monitor syscalls (kernel side) in a non racy way? Modules can [un]register themselves for syscall intercaption, and receive the syscall number and parameters. They'd be able to change paramters, return error codes, and so on. The cost of the check in the syscall path could even be under an alternative-like patching, if really neeeded. The Pros of this would be: - The kernel code to implement this would be trivially small, with no I-need-this-feature-too growth potential - There won't be any externally visible API to maintain (and its kernel counter part) and expand - Any system call can be intercepted, allowing it to be flexible while leaving the burden of the interception handling, and communication with userspace policy enforcers, to the anti-malware (or whoever really) companies modules The anti-malware are already doing this (intercepting syscall), they already have code for it, and they always did (writing kernel modules/drivers, that is) for Windows. - Davide -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jamie Lokier on 21 Sep 2009 19:20 Davide Libenzi wrote: > On Mon, 21 Sep 2009, Jamie Lokier wrote: > > > I think so to, and that'd be a great all round solution. > > If this is for anti-malware vendors Personally I'm not interested in anti-malware, and am simply interested in leveraging fsnotify improvements to accelerate userspace caches of information which depends on files (indexes, templates, compiler caches, stat caches etc.). Basically make inotify better, and sufficiently correct for that purpose. My sticking my oar in lately is to ensure the fsnotify improvements are going in the (imho) right direction. There's a lot of interesting apps waiting in the wings on this. It doesn't have to be complicated, just... sensible. > to intercept userspace accesses > they're currently doing it by hacking the syscall table, why don't we > offer a way to monitor syscalls (kernel side) in a non racy way? > Modules can [un]register themselves for syscall intercaption, and receive > the syscall number and parameters. They'd be able to change paramters, > return error codes, and so on. > The cost of the check in the syscall path could even be under an > alternative-like patching, if really neeeded. > The Pros of this would be: > > - The kernel code to implement this would be trivially small, with no > I-need-this-feature-too growth potential (Fwiw, the {fa,fs,i}notify thing looks to me like it's getting simpler as we go. Good design = decrease complexity + increase versatility. E.g. see epoll.) > - There won't be any externally visible API to maintain (and its kernel > counter part) and expand > > - Any system call can be intercepted, allowing it to be flexible while > leaving the burden of the interception handling, and communication with > userspace policy enforcers, to the anti-malware (or whoever really) > companies modules > > The anti-malware are already doing this (intercepting syscall), they > already have code for it, and they always did (writing kernel > modules/drivers, that is) for Windows. I don't mind at all if fanotify is replaced by a general purpose "take over the system call table" solution for anti-malware, and I still get to keep the fsnotify improvements :-) But I can't help noticing that we _already_ have quite well placed hooks for intercepting system calls, called security_this and security_that (SELinux etc), albeit they can't redirect things so much. However, being a little kinder, I suspect even the anti-malware vendors would rather not slow down everything with race-prone complicated tracking of everything every process does... which is why fanotify allows it's "interest set" to be reduced from everything to a subset of files, and it's results to be cached, and let the races be handled in the normal way by VFS. Once you have an "interest set" and focus on files, it looks somewhat reasonable to use the fsnotify hooks. ....That is, if you believe monitoring files is the best approach to anti-malware. I can't help noticing that on (ahem) Windows, running just a "virus checker" which generically scans every file independent of it's location looking for signatures and keeping up with patches is no longer considered good enough. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andreas Gruenbacher on 21 Sep 2009 19:20
On Tuesday, 22 September 2009 0:00:02 Jamie Lokier wrote: > Andreas Gruenbacher wrote: > > On Monday, 21 September 2009 22:28:23 Jamie Lokier wrote: > > > It would be logical if fanotify could block and ack those [mount & > > > umount events] in the same way as it can block and ack other accesses > > > (with the usual filtering rules on which inodes trigger events, and > > > which don't or are cached). > > > > Hmm. To me, fanotify is about file contents first of all: this is what > > fanotify wants to be able to veto. > > Surely you don't assume that what constitutes malicious content is > independent of it's location and/or name? If the antimalware vendors want to base their decisions on pathnames then that's their decision, and they can check /proc/self/fd/N. We should be able to treat directory events the same. > (See also "echo 'run_virus&' >>.bash_login). > > Wait a minute. You don't assume that, otherwise why the interest in > subtrees? :-) > > > Directory events seem reasonable to add for inotify compatibility, > > Did you see may point about userspace caches and how directory events > are fundamental to that - there's no way to build a cache without them? Yes, there were some doubts about this appoach. Waiting for your code to demonstrate; an object based cache (e.g., st_dev + st_ino) rather than a pathname based cache would seem more reasonable. > > but I see no need for access decisions on them. > > Please excuse me; I'm a bit confused. Is fanotify intended just for > use by access decision programs, or is the plan now for it to also be > a replacement for inotify? I'm getting conflicting signals about > that. Inotify doesn't support access decisions. So where's the problem with having "notify only" events for directory / mount / unmount events? > If it's just for access decision programs, and if those aren't going > to care about location, then there's no need to add directory events > to fanotify at all. But then I'll be demanding subtree support in > inotify, please :-) > > > Even less so for mounts and unmounts. > > (as root) mkdir foo; mount dodgy foo -oloop; mount --bind foo/cat > /bin/cat .... and then someone accesses /bin/cat, which triggers a fanotify access decision. Thanks, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |