Re: recursive commands

[Marcus Brinkmann]

On Tue, Mar 26, 2002 at 03:59:32PM +0100, Oystein Viggen wrote:
> 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. 

This is true.  As I showed you, we give the pick with the lock here :)

> 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 :)

If you want to work on the fix, you will have to understand the problem,
to the extent of knowing the pathname resolution very well.

> > 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?

Yes.  test2 will ask it to retry on test, and rm complies.

> > 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.

certainly 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.

Actually both.  O_NOFOLLOW implies O_NOTRANS in the Hurd, exactly to
prevent such attacks, if the translator is not set by root.  PLease read
the long comment in glibc/hurd/lookup-retry.c about exactly this issue,
and it doesn't harm to read the code, too :)

> OK, so firmlink makes for a successful exploit, from a malicious users
> point of view? 

If the sysadmin is "dumb" enough to do what you said, yes.

> Then it needs to be, and so does a lot of other programs.  (ah, finally
> I found something I can probably work on  ;)

And then people always say that our todo lists are out of date.  This
has been part of the todo list long before even I joined in here.

> > 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.

Definitely.


I am out of time, so I will have to address the details later.

Thanks,
Marcus