[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: recursive commands

From: Oystein Viggen
Subject: Re: recursive commands
Date: Tue, 26 Mar 2002 15:59:32 +0100
User-agent: 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:
>> 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.

When in doubt: Recompile.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]