Re: securety related question...

On Mon, 7 Oct 2002 [email protected] wrote:

> On Sun, 6 Oct 2002, Bill maltby - LFS Related wrote:
> 
> > 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.
> >
> > 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.
> 
> Hardly.
> 
> > 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.
> 
> Or... one would think after all these years you'd realize there's nothing
> particularly wrong with being able to do this.

After all these years, what I have realized is that these systems are
*intended* for users to accomplish productive work, reliably and with
confidence (their bad) in the working environment and results.

> The current working directory is at best, just an environmental
> variable.

Nope. Inside a program (C for example), you can open a file without
referencing any environmental variable. If it is a file that is in the
"current working directory" of the program, no leading path is needed.
So, that means that when the system call is made to open a file, something
in the kernel "knows" where that process is "at". As example, think of
fuser. It does not have access to the environment of the processes that
are using a resource, yet it can tell you what process is using that
resource. As I said in another post (IIRC), there is a control block that
contains the information.

> If you're actually _using_ some of those inodes at the time they're
> delinked, they won't immediately go away.  Open an flock() like you're
> supposed to if you'd like to keep files around--user error is not a
> bug.

Good. You have solved the problem of noobs. Nobody can be just a plain old
user on *IX. They must now all be expert C programmers. This will allow
them to do the normal things that users are supposed to be able to do with
some confidence that the environment they were told to expect will really
exist for the duration of their activities.

-- 
Bill Maltby
[email protected]

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