Re: generic question: user-only directory w/o root access

[Theodore Ts'o <tytso@mit.edu>]

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