[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: recursive commands
Re: recursive commands
Tue, 26 Mar 2002 15:59:32 +0100
Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.1 (Capitol Reef, i386-debian-linux)
* [Marcus Brinkmann]
> On Tue, Mar 26, 2002 at 10:23:08AM +0100, Oystein Viggen wrote:
>> 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"
> 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
Do you mean O_NOTRANS? O_NOFOLLOW seems to be for symlinks, according
>> 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
When in doubt: Recompile.