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 22 Sep 2009 19:50 On Tue, 22 Sep 2009, Jamie Lokier wrote: > Eric Paris wrote: > > That's not the fatal flaw. The fatal flaw is that I am not going to > > write 90% of a rootkit and make it easy to use. > > I hate to point out the obvious, but fanotify's ability to intercept > every file access and rewrite the file before the access proceeds is > also 90% of a rootkit... Obvious, but worth noticing. Indeed, the syscall table has been RO to make it harder for RKs to exploit it, not to make it impossible. RO syscall table makes perfect sense. But, once you are root, with very few lines of code, you can find, prot-fix the page, and patch the table. > But fortunately both fanotify and syscall rewriting require root in > the first place. ^^^^^^^^^ Again, maybe I wasn't clear about how this would work, but the syscall table would continue to remain RO ;) And as I said before, if we want to bring the cost of the interception for non-users pretty close to zero (a few NOPs to run onto), we could even adopt an alternative-like patching triggered by a kernel boot option. - 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 04:50 On Tuesday 22 September 2009 17:04:44 Davide Libenzi wrote: > On Tue, 22 Sep 2009, Andreas Gruenbacher wrote: > > The fatal flaw of syscall interception is race conditions: you look up a > > pathname in your interception layer; then when you call into the proper > > syscall, the kernel again looks up the same pathname. There is no way to > > guarantee that you end up at the same object in both lookups. The > > security and fsnotify hooks are placed in the appropriate spots to avoid > > exactly that. > > Fatal? You mean, for this corner case that the anti-malware industry lived > with for so much time (in Linux and Windows), you're prepared in pushing > all the logic that is currently implemented into their modules, into the > kernel? 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. 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: hch on 23 Sep 2009 07:30 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. -- 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: Arjan van de Ven on 23 Sep 2009 07:40 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.... -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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 11:30
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? 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. - 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/ |