Re: securety related question...

[06.10.2002] Bill maltby - LFS Related <-- :
> On Mon, 7 Oct 2002, Erika Pacholleck wrote:
> 
> > [06.10.2002] Bill maltby - LFS Related <-- :
> > > On Sun, 6 Oct 2002, Erika Pacholleck wrote:
> > > > suddenly a by intention mounted ro partition will be rw, and what you
> > > > believe protected by ro is suddenly deleted via the bound mounting point!
> > > 
> > > So? I see no problem with that. Further, it is no different than current
> > > (flawed) *IX implementations for directories. Have some fun, try this.
> 
> I should have been more explicit in my intent.
> Given this directory structure
>     /tmp
>        /todel
>             /todel2
> One process changes directory as follows
>     cd /tmp/todel/todel2
> Another process does rm -rf /tmp/todel. The first process now does
>     cd ..
> The result is
>     cd: could not get current directory
>     cd: could not get current directory
> After the pwd -P, the result of a cd .. is
>    cd_links: could not get current directory

Correct, you are using a relative cd-ing, and if there is no reference
point to the ".." those messages *tell* you what is the matter. And if
you don't listen to that you can really get into a far bigger mess, if
you rely on what bash tells you.

At least here, /bin/pwd is able to return the correct path if there
is a valid directory I am in (which bash fails, not to speak of that
annoying PS1 \w remaining as long as you use relative cd-ing). This is
why I said, the main issue seems to be bash in this case. And
unfortunately an ancient /bin/cd was given up because "every shell is
expected to have it integrated" (I am implementing here that an
independent /bin/cd would be able to work according to /bin/pwd).

> Obviously not a bash flaw - it does not have file-system notification
> capability. But the kernel *is* aware of these things. The problem is that
> it has allowed removal of a directory structure that invalidates the cwd
> of an active process. For mounts, there is a "use count" that prevents
> unmounting an "active" file system. This is with good reason.

This means you must monitor for everything the current directory and
changes of that and additionally stop an rm command if it effects an
"active" directory, right? How much monitoring activities will that be
for some thousand processes?
Or do you mean this monitoring *is* already done and that "stopping rm"
is the only thing missing?

> I have always considered the failure of the kernel to provide a similar
> protection for "active" directory paths to be a flaw either in design or
> implementation. The net effect of the above example is to invalidate the
> environment of a properly operating process. Although I have not invest-
> igated the potential, I think that it might also provide opportunity for a
> security breach.

If someone else is faster in deleting than you ..

And now with view to mount --bind with a change from ro to rw, we have
the same situation here, don't we? I mean, there is a reason why I mount
only var, tmp and home rw, nothing has the right at all to write onto any
other partition, not even root, same as other mount options were made to
use them and not for decorating fstab. And you would not "--bind -o rw" if
you would not willingly intend to write/delete something, right?

So on one hand you complain about the possibility to delete "active"
directories and on the other hand you want to introduce rw possibilities
for an already ro mounted partition together with --bind.
If I understood your path-bound thoughts correctly (did I?), it should be
possible to `mount / ro` 
and then    `mount --bind -o rw / /tmp/.hidden`
and root@localhost:~            can't do `rm -f /bin/*`
but root@localhost:/tmp/.hidden can do   `rm -f /bin/*` ??

What's so wrong using the remount option and have it effect the partition
as is, no matter where it is mounted? You are free in the choice of your
partitions and how to bring them together.

> Every *IX I have worked on has had this weakness. One would think that
> after all these years, all implementations would have remedied this
> situation.

Ok, deleting an active directory is possible (excuse "known issue"), but
trying this on a ro mounted partition is not, not without remount, and
to my mind this is also with good reason.
-- 
Erika ...---...: pacholleck at nexgo dot de
-- 
Unsubscribe: send email to [email protected]
and put 'unsubscribe lfs-security' in the subject header of the message