Re: FUSE merging?

[Miklos Szeredi <miklos@szeredi.hu>]

> > 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.

Well, I think it's a fertile ground for hole hunters out there.  Just
needs a little publicity ;)

Is it considered DoS for example if I prevent other users from sending
email?  SIGSTOP on sendmail at the right moment (when the database is
locked) should do it fine.

> 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.

On a well protected multiuser system there will be ulimits in place to
prevent that.

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

Killing always works, if the sysadmin happens to be around.  If not
then there's not a lot other users can do.

> 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.

You mean suid programs are never to touch paths passed to them?

If that would be true, then fuse_allow_task() would not be needed, but
would do no harm either, since it would never be invoked by a suid
program.

> > 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.

You didn't consider the information leak aspect (point B in fuse.txt).

> -	some sort of "intr" mount option for most signals on by default.

KILL will always interrupt a request.  So getting rid of a malicious
mount should present no problems.

> -	Forbid hiding data by mounting a FUSE filesystem on top of it (does
> 	FUSE check for this already?)

Yes.  It checks for writablilty on the mountpoing (excluding limited
writablilty as /tmp for example).

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

Been there.  People (like Al Viro) didn't like it.

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/