Re: lynx-dev symlinks to other users' files; broken symlinks

[Benjamin C. W. Sittler]

On Sat, 10 Oct 1998, Philip Webb wrote:

> 981010 Benjamin Sittler wrote: 
> > Symlinks to other people's files are often used here at the New Mexico
> > Tech Computer Center so that a large group of users can share a single,
> > easily-updated configuration file for Lynx, FVWM, or some other package.
> > There are several of these widely-used configuration files, none of them
> > controlled by the computer center (they have their default system.fvwmrc
> > and lynx.cfg, though, so you can still use these programs without a copy
> > or symlink to someone's .fvwmrc or .lynxrc.)  This is great, as it allows
> > users to easily adopt each other's settings, without the synchronization
> > problems introduced by copying.  Obviously, this requires a relation
> > of trust between the user maintaining the file & the users symlinking to it

> this appears to be a case where User A deliberately permits User B
> to make a symlink to User A's file, presumably setting  -rwxrwxrwx :
> User A MUST give permission or anyone could symlink to anyone else's files.
> that can never raise security concerns about malicious misuse:
> User A fully expects User B to write into User A's file sometimes.

No, the file linked to is only writable by User A. The symlink, of course,
appears to have all permission bits set, but that's an artifact of the way
symlinks are handled in UNIX.

> > Broken symlinks (that is, symlinks to non-existent files) are also
> > quite common, as the systems at the computer center do not have totally
> > homogeneous filesystem layouts.  It's often useful to link to a
> > machine-local configuration file, and fall back on a global system default
> > configuration file if the machine-local configuration file does not exist.

> you've lost me with your sudden jump to talking about "machines":
> do you mean virtual machines a la VM-CMS or networked machines of some kind?

Machines = networked computers, in this case. Sun SPARCs running SunOS,
Solaris and Linux/SPARC, PCs running Linux/i386, an Alpha or two running
Digital UNIX and Linux/Alpha, etc. 

> > EG User A might have a custom configuration for lynx that he's trying
> > on his own machine, and so he has a symlink pointing from .lynxrc
> > in his home directory to wherever the custom .lynxrc is on his machine.
> > But he'd still like to use Lynx on other machines, and doesn't want
> > to worry about his (possibly-broken) custom configuration
> > except when using his own machines.

> so what are these machines & how does he get to use other people's?

NFS, the Network File System, allows directories and files to be
distributed to many machines. But an office machine (for example) won't
have its directories exported, so User A won't have to worry about the
experimental lynxrc except when using his own machine.

> > Ideally, he'd like Lynx to use the global lynx.cfg (only) on most machines,
> > but also his personal lynx.cfg on his machine.  This means
> > that on most machines, .lynxrc will be a broken symlink
> > (probably to a directory that doesn't even exist elsewhere.)

> i have no problem at all with symlinks which point to non-existent files:
> the issue is how symlinks can threaten security on a properly managed system.

Symlinks to non-existent files can be a security threat if it's possible
for a malicious user to create the previously nonexistent destination
file. For example, if /u/bsittler/.lynxrc were a symlink to /tmp/.lynxrc,
and /tmp/.lynxrc didn't exist on some machine where /tmp was
world-writable, someone else could write a /tmp/.lynxrc on that machine
which Lynx would read when bsittler used that machine. This is a security
hazard since the malicious .lynxrc could tell lynx to fetch through a
transparent proxy which (say) logs all form submission contents.

If the directory doesn't have the sticky-bit set (or the operating system
doesn't support sticky-bits,) even a non-broken symlink into a world
writable directory can be a security hazard, since a malicious user could
rename or remove the linked-to file and replace it with a dangerous
version.

On the other hand, in some environments this is no threat at all, and can
actually be useful. When malicious users are not an issue, having .lynxrc
in a world-writable directory can be very useful, since several users can
share the same file, and any one of them can modify it (to fix a problem,
say, or to add a URL guessing scheme.)

Lynx should, in my opinion, be able to cope with both cases. At the very
least there should be a compile-time option to control this behavior. I'm
not sure what the default should be, though.

Anyhow, is this sort of security really Lynx's business at all? It seems
to me that managing symlink security is an issue for the user (who
presumably created the link in the first place) to deal with. Let the
users be responsible for their own mistakes, and teach them the dangers of
symlinks to world-writable directories outside the context of Lynx. A
little education can go a long way towards making Lynx's job easier.

> > There are many more arcane reasons to allow lynx to use symlinked files
> > owned by other users, and to gracefully ignore broken symlinks.
> > Send me private email if you are interested in them,
> > as this message is rather long already.

> i'm certainly grateful for your thoughts, which are relevant to lynx-dev.
> i've been deliberately shining a light into some dark corners
> where cobwebs have been collecting for too long.

Well, this is really a security issue which has more to do with UNIX
in general than with Lynx. I'll always have my Lynx setup to *not* check
symlinks for percieved potential security problems, since I expect Lynx to
do exactly what I tell it to without my having to recompile.

Even in a well-administered system with many potentially-malicious users,
allowing users to shoot themselves in the foot is probably more useful
than preventing some creative collaboration of a form the administrator
may not have considered.

Remember, the system is there for the users, not for the administrators.
And if a user opens himself up to attack from other users, that's not the
administrator's problem (unless that user happens to be the administator!)