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: Jamie Lokier on 21 Sep 2009 20:00 Andreas Gruenbacher wrote: > If the antimalware vendors want to base their decisions on pathnames then > that's their decision, and they can check /proc/self/fd/N. Race hazards and loopholes. It doesn't work. > 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. Nearly everything that people do with files involves paths. The point is to cache what people (or their programs) do. Apache does not consult inodes by number, and rsync does not write inodes by number :-) Yes, to the code... > > > 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? No problem here. You seemed to be saying you want to add directory events to fanotify. But if fanotify is only intended for access decisions? Something I must have misunderstood in 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 > > ... and then someone accesses /bin/cat, which triggers a fanotify access > decision. That's fine as long as there was no location-awareness in the logic which checked foo/innocent.txt and set that inode's "read-ok,cache-me" bit. Mount only matters if you're sensitive to location. If you think location-independent checks make good anti-malware I_have_a_bridge_to_sell^H^H^H^H^H^H^H^H^H^H^Hfine with me :-) -- 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: Eric W. Biederman on 21 Sep 2009 20:20 Linus Torvalds <torvalds(a)linux-foundation.org> writes: > Quite frankly, I have _never_ever_ seen a good reason for talking to the > kernel with some idiotic packet interface. It's just a fancy way to do > ioctl's, and everybody knows that ioctl's are bad and evil. Why are fancy > packet interfaces suddenly much better? For working with the networking stack there are a lot of advantages because netlink is the interface to everything in the network stack. There are nice things like the packet to create a new interface is the same packet the kernel sends everyone to report a new interface etc. netlink also seems to get the structured data thing right. You can parse the packet even if you don't understand everything. Each tag is well defined like a syscall, taking exactly one kind of argument. Which avoids the worst failure of ioctl in that you can't even parse everything, and the argument may be a linked list in the calling process or something else atrocious. All of that said syscalls are good, and I would not recommend netlink to anything not in the network stack. 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: Randy Dunlap on 21 Sep 2009 20:30 On Mon, 21 Sep 2009 17:15:28 -0700 Eric W. Biederman wrote: > Linus Torvalds <torvalds(a)linux-foundation.org> writes: > > > Quite frankly, I have _never_ever_ seen a good reason for talking to the > > kernel with some idiotic packet interface. It's just a fancy way to do > > ioctl's, and everybody knows that ioctl's are bad and evil. Why are fancy > > packet interfaces suddenly much better? > > For working with the networking stack there are a lot of advantages because > netlink is the interface to everything in the network stack. > > There are nice things like the packet to create a new interface is the same > packet the kernel sends everyone to report a new interface etc. > > netlink also seems to get the structured data thing right. You can > parse the packet even if you don't understand everything. Each tag is > well defined like a syscall, taking exactly one kind of argument. > Which avoids the worst failure of ioctl in that you can't even parse > everything, and the argument may be a linked list in the calling > process or something else atrocious. > > All of that said syscalls are good, and I would not recommend netlink > to anything not in the network stack. like CONFIG_SCSI_NETLINK and CONFIG_QUOTA_NETLINK_INTERFACE :( --- ~Randy -- 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 22 Sep 2009 11:00 On Tue, 22 Sep 2009, Jamie Lokier wrote: > I don't mind at all if fanotify is replaced by a general purpose "take > over the system call table" solution ... That was not what I meant ;) You'd register/unregister as syscall interceptor, receiving syscall number and parameters, you'd be able to return status/error codes directly, and you'd have the ability to eventually change the parameters. All this should be pretty trivial code, and at the same time give full syscall visibility to the modules. The complexity would be left to the interceptors, as they already do it today. > 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), ... That has "some" limits WRT non-GPL modules and relative static linkage. > 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. They are already doing it today, since they are forced to literally find and hack the syscall table. They already have things like process whitelists, path whitelists, scan caches, and all the whistles, in their code. Of course, some of them might be interested in pushing given complexity inside the kernel, since they won't have to maintain it. Some other OTOH, might be interested in keeping a syscall-based access, since they already have working code based on that abstraction. The good part of this would be that all the userspace communication API, whitelists, caches, etc... would be left to the module implementors, and not pushed inside the kernel. That, and the flexibility of being able to intercept all the userspace entrances into the kernel. - 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: Andreas Gruenbacher on 22 Sep 2009 11:40
On Tuesday, 22 September 2009 16:51:39 Davide Libenzi wrote: > On Tue, 22 Sep 2009, Jamie Lokier wrote: > > I don't mind at all if fanotify is replaced by a general purpose "take > > over the system call table" solution ... > > That was not what I meant ;) > You'd register/unregister as syscall interceptor, receiving syscall number > and parameters, you'd be able to return status/error codes directly, and > you'd have the ability to eventually change the parameters. All this > should be pretty trivial code, and at the same time give full syscall > visibility to the modules. 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. 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/ |