Re: securety related question...

On Mon, 7 Oct 2002, Erika Pacholleck wrote:
> [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
> <snip>

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

?? On my system (LFS 4.0), both pwd -P, echo $PWD return the same thing.
If they are done *before* the cd .., they both show the expected path. If
done *after* the cd .., they both show the same error message. So, I say
it is not a bash problem because the independent /bin/pwd returns the same
as bash's builtin echo. It is a kernel or library problem.

Further, another twist is added if you look at ls's (and other utility
commands) behavior before and after the "cd ..". Before the "cd ..", "ls
-a .." returns nothing and sets a "success" return code. This is an error.
After the "cd ..", "ls -a .." returns the contents of the last level of
the directory it could successfully process. This could be considered
correct, from the programmers view. But I think since there is no valid
current working directory any longer, it is *not* valid to assume the
last-known working directory and follow a path based on that. I think that
all utilities should return failure before and after the "cd ..".

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

But it would not. Here is the deal. Regardless of integration, when a "cd
.." is done, the utility must read the current directory (unless is saved
it) and get the entry for "..". This will give an i-node that can then be
used to "open" the referenced directory. But, in the example I gave, that
directory no longer exists. So an independent "cd" would behave like the
current "cd" or "ls" and so on. Its only option is if it saved previous
path-component information. Then it could say "I don't have a valid ..,
I will go to the last valid component I know about". It might give a
message so the user would be aware.

> > Obviously not a bash flaw - it does not have file-system notification
> > <snip>

> 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 haven't looked. And the amount of monitoring is an issue. It would
similar to mount's overhead but could be excessive with every find
/ causing great overhead. Think of the scenario.

    /mnt/hd1          # A mount right under root
        /mnt/hd1/hd2  # A mount right under /mnt/hd1

If you now try to umount /mnt/hd1, it will fail. Why? Because the system
"knows" it is busy _even_if_there_is_no_process_in_/mnt/hd1/hd2. This is
because the use count of the /mnt/hd1 partition was incremented when
/mnt/hd1/hd2 was mounted. For commands like find, if the use count was
updated for each step in the path, overhead would be horrendous.

But, it is certainly *not* valid for utilities to behave as they do
now. There is not, AFAIKT, an *easy* low-overhead solution. But there are
several solutions available, even with my limited knowledge.

> > I have always considered the failure of the kernel to provide a similar
> > [...] 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?

I think a policy of "--bind with same or more restrictive permssions but
not less restrictive..." would work just fine. And could satisify most
needs. You could "share" a directory down in a mounted partition that was
rw, but make the shared thing ro. Sharing a base that was ro as --bind rw
would not be valid.

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

Yes. My preference would be that deletion of paths up to and including an
"active" one could not be deleted. And mount --bind would have to honor
this *if* the rest of the system honors it. Consistency counts. If the
rest of the system does *not* honor it, then why penalize mount by asking
for a restriction on it that the rest of the system does not share?

Consistency counts.

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

No. rw is less restrictive than the ro of the "base" mount. It is not
allowed, in my theoritical universe.

> and root@localhost:~            can't do `rm -f /bin/*`
> but root@localhost:/tmp/.hidden can do   `rm -f /bin/*` ??

If / was mounted rw, and /tmp/.hidden were ro, root could rm -rf /bin
(accepting the current system behaviour - not what I would prefer) and
anything in /tmp/.hidden would/should behave like the rest of the system.
But, rm -rf on /tmp/,hidden would *not* be permitted, even by root.

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

Nothing *so* wrong, just looking for more capability as with any other
utility function. If --bind allowed additional parameters (like ro, exec,
noexec, nosuid, suid...) that did not *increase* effective permissions,
there are some nice things that inventive folks do with it.

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

Yes. But as above, I would *not* advocate less restrictive --bind
mounts. Only same/more restrictive options.

And, I would ask only behavior consistent with the rest of the system
(which I would like to be more "correct").

-- 
Bill Maltby
[email protected]

-- 
Unsubscribe: send email to [email protected]
and put 'unsubscribe lfs-security' in the subject header of the message