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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |