![]() | |||||||||||||
Messages in this thread |
> > > > - 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/ | ||||||||||||
| Last update: 2005-07-01 09:05 [from the cache] ©2003-2008 | |||||||||||||