On Sat, Jun 06, 2015 at 07:46:14PM +0200, U.Mutlu wrote: > Theodore Ts'o wrote on 06/06/2015 05:42 PM: > >On Sat, Jun 06, 2015 at 09:19:40AM +0200, U.Mutlu wrote: > >>I posted hello.c (a FUSE demo) in this thread. It is IMO even more secure > >>than the private namespace mount method. The simple reason is: > >>because granting access to the volume (or to a single dir/file) > >>is done inside that user-code itself, ie. the user/owner controls > >>whom he actually gives access. > >>I'm sorry to say this, but this simply proves your last statement above wrong. > > > >So the root user ptraces the FUSE daemon, and it's all she wrote. > > Protection against tracing and debugging: > inside the user-application ie. here the FUSE-client, > and also inside the FUSE daemon: > > ptrace(PT_DENY_ATTACH, 0, 0, 0); > > Of course one would need to recompile the FUSE daemon. > The company can enforce such a security policy. And so the root user can install a kernel module which toggles the PT_DENY_ATTACH flag for the FUSE daemon after it's started. Or it could use a kprobe or jprobe to dynamically patch the ptrace system call to cause it to disregard that flag. (Or use the ksplice funcionality which would make life even easier.) > And while we are at it, I would add a new option to the FUSE daemon, > so that the client-app can query it before issuing the mount call, > whether it has that protection built in or not, and proceed accordingly... > IMO a solvable problem. And root can cause the kernel to lie to client applications. Next? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
