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: Davide Libenzi on 23 Sep 2009 11:40 On Wed, 23 Sep 2009, hch(a)infradead.org wrote: > On Wed, Sep 23, 2009 at 09:39:33AM +0100, Tvrtko Ursulin wrote: > > Lived with it because there was no other option. We used LSM while it was > > available for modules but then it was taken away. > > > > And not all vendors even use syscall interception, not even across platforms, > > of which you sound so sure about. You can't even scan something which is not > > in your namespace if you are at the syscall level. And you can't catch things > > like kernel nfsd. No, syscall interception is not really appropriate at all. > > The "Anti-Malware" industry is just snake oil anyway. I think the > proper approach to support it is just to add various no-op exports claim > to do something and all the people requiring anti-virus on Linux will be > just as happy with it. The fear is that this becomes a trojan horse (no pun intended) for more and more hooks and "stuff", driven by we-really-need-this-too and we-really-need-that-too. And once something it's in, it's harder to say no, under the pressure of offering a "limited solution". This ws the reason I threw the syscall tracing thing in, so they have a low level generic hook, and they cam knock themselves out in their module (might need a few exports, but that's about it). - 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: Tvrtko Ursulin on 23 Sep 2009 11:50 On Wednesday 23 September 2009 12:32:32 Arjan van de Ven wrote: > On Wed, 23 Sep 2009 09:39:33 +0100 > > Tvrtko Ursulin <tvrtko.ursulin(a)sophos.com> wrote: > > Lived with it because there was no other option. We used LSM while it > > was available for modules but then it was taken away. > > ... at which point you could have submitted your LSM module for > inclusion... you'd be the first (and only?) Anti Virus vendor that > would be in the mainline kernel.. speaking of competitive advantage, > coming out of the box in all distributions. > > sadly this road hasn't been chosen.... It has, but since what we had wasn't acceptable the road was long and it turned into fanotify. Which is not only about anti-malware (hello Christoph) so I think this sub-thread is going off-topic. Tvrtko -- 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: Tvrtko Ursulin on 23 Sep 2009 11:50 On Wednesday 23 September 2009 16:26:49 Davide Libenzi wrote: > On Wed, 23 Sep 2009, Tvrtko Ursulin wrote: > > Lived with it because there was no other option. We used LSM while it was > > available for modules but then it was taken away. > > > > And not all vendors even use syscall interception, not even across > > platforms, of which you sound so sure about. You can't even scan > > something which is not in your namespace if you are at the syscall level. > > And you can't catch things like kernel nfsd. No, syscall interception is > > not really appropriate at all. > > Really? > And *if* namespaces were the problem for the devices you were targeting, > what prevented you to resolving the object and offering a stream to > userspace? You are right, nothing really, we even do it like that today. But what about other interested users? > In *your* module, hosting at the same time all the other logic required > for it (caches, whitelists, etc...), instead of pushing this stuff into > the kernel. > WRT to the "other" system, never said they were using syscall > interception, if you read carefully. I said that minifilters typically > sends path names to userspace, which might drive you in the pitfall > Andreas was describing. Yeah, you could do something like kauth on OSX, which is I guess similar to LSM, which was turned off for out of tree. And now you want to push users of fanotify out of tree, so what should it be? In tree bad, out of tree bad? Tvrtko -- 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: Eric Paris on 23 Sep 2009 12:00 On Wed, 2009-09-23 at 13:32 +0200, Arjan van de Ven wrote: > On Wed, 23 Sep 2009 09:39:33 +0100 > Tvrtko Ursulin <tvrtko.ursulin(a)sophos.com> wrote: > > > Lived with it because there was no other option. We used LSM while it > > was available for modules but then it was taken away. > > ... at which point you could have submitted your LSM module for > inclusion... you'd be the first (and only?) Anti Virus vendor that > would be in the mainline kernel.. speaking of competitive advantage, > coming out of the box in all distributions. And users would be left in a situation between choosing an LSM which actually does in provable ways increase security and using an AV scanner. Until magic solves the LSM stacking problem (it's been tried, no magic) I don't think any distro wants AV vendors as LSMs. -Eric -- 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 23 Sep 2009 13:40
On Wed, 23 Sep 2009, Tvrtko Ursulin wrote: > Yeah, you could do something like kauth on OSX, which is I guess similar to > LSM, which was turned off for out of tree. And now you want to push users of > fanotify out of tree, so what should it be? In tree bad, out of tree bad? As I said before, the good of a syscall tracing approach, is that it is a completely generic mechanism (extensible for other kind of hooks too), with minimal kernel impact, while allowing its module-users to stuff all the code they want in the part that it's their responsibility. So that a "we need this too" gets translated to "just do it in your code", instead of a request to add more stuff into the kernel, and maybe altering the userspace access interface (which is always painful). - 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/ |