* [Marcus Brinkmann] > On Tue, Mar 26, 2002 at 10:23:08AM +0100, Oystein Viggen wrote: >> Hi >> >> I was wondering: If a user attaches a translator to a node in "/tmp" that >> shows, say, "/etc", "/sbin", "/", or something else, and root runs "rm >> -Rf /tmp", what will happen? > > You are not creating a full scenario here, "to show" is not a filesystem > concept in the Hurd, so I can only guess what you mean.
I'm not so good at this, but I think what I mean is really "any way at all you can accomplish what I describe". For a translator aware rm, we need to be able to deal with any kind of user defined translator, not just what we currently have. I should probably spend some time reading up on how things actually work under the hood. I've been thinking mostly in terms of a user or a user space programmer, in a kind of "press this pedal, and it goes faster" fashion :) > However, you are right that there is such a condition. If you firmlink > a directory, rm will traverse into this directory. > > As root: > mkdir test > touch test/foo > As user: > settrans -ac test2 /hurd/firmlink test > As root: > rm -fR test2 I guess the important thing here is that rm will be doing its own reading of test and get its own port to foo? > And test/foo will be gone. Note that in the tmpreaper function in > libexec/rc, we are carefully removing translators first. This is nice, but I figure the program tmpreaper in debian does not. > Note that if you open node with O_NOFOLLOW, translators will not be > followed, so some of such attacks are stopped by this. However, rm is > not suspecting that a directory could be anything that it shouldn't > follow. Do you mean O_NOTRANS? O_NOFOLLOW seems to be for symlinks, according to fcntl.h. >> Will it be: >> 1. rm sees a directory, recurses, and deletes a lot of important files? >> 2. rm sees a directory and recurses, but because the translator is >> running as, say, oysteivi, the ports provided won't give access to >> actually delete stuff oysteivi couldn't delete himself? or > > If you use a firmlink, the translator will redirect the user to the > other node, and the user will open it himself (retry). This is why the > permissions are there. OK, so firmlink makes for a successful exploit, from a malicious users point of view? >> 3. rm sees a translator not owned by any id possessed by the current rm >> process, tries to remove the translator and go on? > > rm is not translator aware. Then it needs to be, and so does a lot of other programs. (ah, finally I found something I can probably work on ;) > Seems so. You definitely have to be much more careful with rm -r in > a space you don't own. userdel -r springs to mind. > We will need to discuss the details here. In general, translators > should be transparent except whena special option is given. For rm -r, > I am not so sure. I think rm -r will follow mount points in other Unix systems, but then again in other systems mount is something deliberately done by root. I think a sane way for rm -r to behave would be to walk into directories provided by translators only when the owner of the node is in rm's id set. This would mean that both I and root can rm -R our own translator trees, while root's rm -R will do something akin to settrans -fg on my translators. A switch for recursing into other peoples translators might be asked for, but I'm not sure if we even want this. (can a translator refuse to remove itself from the filesystem, or will this happen forcibly and instantly, so that the next line in the C program can consider it gone?) What is a safe way of chdir'ing into a users directory, avoiding races, anyway? We can't just check that it's not a translator and then chdir, as that's racey. How about opening any directory not owned by the user running rm with O_DIRECTORY|O_NOTRANS and then doing an fchdir? Questions like this always give me a coffee underrun. >> Is putting the important code inside >> "#ifdef _HURD_" or somesuch advisable? (do we even have such a #define >> to lean on?) > > We have __GNU__, don't use it. Write an autoconf check. For the > features you need. #ifdef HAVE_TRANSLATORS, then. I'm probably overdue for learning autoconf anyway. Oystein -- When in doubt: Recompile. _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd
