Re: FUSE merging?

[Frank van Maarseveen <frankvm@frankvm.com>]

On Fri, Jul 01, 2005 at 08:58:05AM +0200, Miklos Szeredi wrote:
> > > 
> > > - 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?

That's what I though too so I asked it first on the security mailing list.
Apparently this signal behavior is normal.

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

Stopping is a special case. But it is effectively the same as being
indefinately slowed down by, say, 10000+ malicious processes and from
that angle I don't see a fundamental difference w.r.t. security.

Killing the malicous processes should solve the problem. And killing
one FUSE process looks easier to me than killing 10000+ ones.

> Yes.  The extra problem with FUSE, is that they are not _able_ to be
> careful.

I think this is not true. Every pathname passed to a setuid program
by the user is basically "tainted". Standard I/O is tainted as well.

> They can't even check if a file is in fact on a FUSE mount

They shouldn't. The pathname is not to be trusted anyway.

I think FUSE has shown to be conservative enough w.r.t. security to be
merged. But it may be interesting to consider:

-	replace ptraceability test by a kill()ability test.
-	some sort of "intr" mount option for most signals on by default.
-	Forbid hiding data by mounting a FUSE filesystem on top of it (does
	FUSE check for this already?)
-	/proc isn't a problem: most root processes tend to avoid it because
	it is synthetic and thus uninteresting. Maybe we should extend
	the idea of "synthetic file-systems being uninteresting" to any
	process which cannot receive signals from the FUSE mount owner. When
	one cannot hide data by a FUSE mount and its synthetic anyway so not
	interesting then just show the original empty mount point.

-- 
Frank
-
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/