Re: lynx-dev Re: who owns what

[Bela Lubkin]

Philip Webb wrote:

> 981009 Bela Lubkin wrote: 
> > Philip Webb wrote:
> >> how can the Enemy place a link in  ~/purslow ?  i own it.
> >> maybe in  /tmp , if the link is to a file under  ~/purslow ,
> >> but that's never going to be the case with  .lynxrc .
> > Enemy can't; the problem is that Lynx is using the same function
> > to check the safety of writing the .lynxrc as for writing a temp file.
> 
> but why ever would Lynx be programmed to use the same function to do both?
>  /tmp  may be written by lots of people & could be dangerous,
> but as i said,  .lynxrc  is always going to be in  $HOME ,
> which is in any case otherwise identifiable to Lynx in several ways.
> trying to remove an obscure security risk by screwing up  .lynxrc
> is not at all impressive programming.

It's just a utility function that Lynx now uses to open files.  Now that
he has the evidence, Tom will fix it, and I'll review the whole thing
some time in the future because I'm pretty sure there are still some
security holes in it.  (The old holes were blatant; the new ones, with
Tom's recent changes, require more effort on the attacker's part,
because they're race conditions.  But they still should be fixed.)

> >> so why did the problem arise explicitly for anonymous Enemies,
> >> as is shown by the messages in the Archive i referred to yesterday?
> > You referred to 2 months worth of messages, -- I didn't go looking.
> > I'll follow a direct URL to a specific message.
> 
> that's exactly what i gave: number links, goto the Archive HTML version
> & look at Sep [445 662 769] & Aug [11]: TD LP & Mike Castle are authors.
> they explicitly refer to ANONYMOUS use as the problem.

Those aren't URLs.  I have neither a bookmark nor a mental reference to
"the Archive HTML version".  And I'm not particularly interested in
looking at those messages, which, if they say what you claim, are
simply wrong.

> >> nothing you've said above establishes there could be a problem
> >> on an ordinarily well-managed UNIX site without anonymous users,
> > There could be.  Even with a sticky /tmp directory, there are ways
> > to attack, and the code you patched out attempts to avoid those.
> 
> so are you saying that UNIX is inherently unsafe?

There are many inherently unsafe operations in Unix (as in any operating
system); one must program with care.

> ie you always have to check programs in detail
> to ensure you aren't open to the kinds of attacks described on lynx-dev?

If you are concerned about security, all software must be audited.
There are groups of people doing this for various software.

> that sysadmins who know what they are doing still can't prevent it?
> that anyone can set up a symlink to a file they don't own?
> the last of these is the gist of the danger you describe
> & i'm amazed if that is really the case:
> surely someone would long ago have brought out a new version of UNIX
> which is protected against it: there are lots of UNICES, after all.

It is the nature of symlinks.  For instance, you can create a symlink to
a file that does not (yet) exist.  If that file was later created, and
you didn't have permissions to that file, the pre-existing symlink would
violate your premise (no symlinks to files you don't have permission
to).  But to prevent that, the operating system would need a reverse
index of symlinks, which it doesn't have and which would be a
maintenance nightmare.

Symlinks to not-yet-created files have several important uses.  So do
symlinks to not-owned files.  Removing those abilities would be both
difficult and damaging to the normal operation of the system.

>Bela<