Re: FUSE merging?

[Miklos Szeredi <miklos@szeredi.hu>]

> > 
> > - Frank points out that a user can send a sigstop to his own setuid(0)
> >   task and he intimates that this could cause DoS problems with FUSE.  More
> >   details needed please?
> 
> It's the other way around:
> Apparently it is not a security problem to SIGSTOP or even SIGKILL a
> setuid program. So why is it a security problem when such a program is
> delayed by a supposedly malicious behaving FUSE mount?

Perfectly valid argument.  My question: is it not a security problem
to allow signals to reach a suid program?

> I think that setuid programs take too many things for granted, especially
> "time". I also think the ptrace equivalence principle (item C2 in the
> FUSE doc) is too harsh for FUSE.

It's obviously not equivalence.  FUSE filesystem gets a subset of
ptrace's capabilities (and rather a small one).

> Suppose the process changes id to full root and we can no longer send
> signals to it. Are there any other ways we could affect its scheduling
> without FUSE? I think "yes", clearly not that easy as when it accesses a
> FUSE mount but "yes". Think about typing ^S (XOFF), or by letting it read
> from a pipe or from a file on a very very slow device. Or by renicing
> the parent in advance. Regarding the pipe: yes the setuid program could
> check that with fstat() but is such a check fundamentally the right
> approach? I have doubt because unified I/O is a good thing and there is
> no guarantee whatsoever about completion of any FS operation within a
> certain amount of time. Suppose another malicious process does a lookup
> in a huge directory without hashed names? What about a process consuming
> lots of memory, pushing everything else into swap? What about deleting
> a _huge_ file or do other things which might(?) take a considerable
> amount of kernel time? [id]notify might even help using this to delay
> a root process at a crucial point to exploit a race. So, I think there
> are many ways to affect the execution speed of [setuid] programs. I
> have never heard of a setuid root program which renices itself, such,
> that it successfully avoids a race or DoS exploit.

There's a huge difference between slowing down, and stopping a
process.  I wouldn't consider the first a true DoS. 

> And then the DoS thing using simulated endless files within FUSE. It is
> already possible to create terabyte sized [sparse] files. Can the fstat()
> size/blocks info be trusted from FUSE? no more than fstat() outside FUSE
> because the file may still be growing!
> 
> > - I don't recall seeing an exhaustive investigation of how an
> >   unprivileged user could use a FUSE mount to implement DoS attacks against
> >   other users or against root.
> 
> In general I think it is _hard_ to protect against a local DoS for many
> reasons and I don't see any new fundamental problem here with FUSE:
> it is just making it more obvious that it's hard to write secure setuid
> programs. Those programs should _know_ that input data and anything else
> from the user is "tainted" and that they must be _very_ careful with it,
> in every detail.

Yes.  The extra problem with FUSE, is that they are not _able_ to be
careful.  They can't even check if a file is in fact on a FUSE mount
or not without the FUSE daemon's intervention (lookup on a file will
be passed to userspace).

Thanks,
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/