Theodore Ts'o wrote on 06/06/2015 09:48 PM:
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.)
I could be wrong but I think the DENY_ATTACH is under the control
of the running app itself.
Not sure if any other process can change that on behalf of the app.
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?
User or his app could check the hash of the kernel file to be sure
it's still the official kernel.
--
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
