Re: lynx-dev Re: who owns what

[Philip Webb]

981011 Bela Lubkin wrote: 
> Philip Webb wrote:
>> suppose i have a file  /homes/purslow/vital
>> & Enemy creates a symlink to it called  /tmp/dagger :
>> on CHASS the latter will have the permission  lrwx------ ,
>> ie only Enemy can (over)write  /tmp/dagger -> /homes/purslow/vital ,
>> but no-one else can, incl me running Lynx.
>> further, Enemy's write permission for  /tmp/dagger  can't allow him
>> to overwrite just ANY file out there he chooses to link it to:
>> it's a danger ONLY if he can delude ME into doing it for him,
>> eg by running a suitable version of Lynx (or some other program).
> The enemy doesn't create  /tmp/dagger , he creates  /tmp/L1234-1TMP.html ,
> which is a name that Lynx will use when you run it.  When Lynx writes
> to that file on your behalf, it will overwrite your  /homes/purslow/vital .

i understand the point about the use of predictable names in  /tmp
-- i use `dagger' to make the discussion easier to follow -- ;
the question revolves around permissions:
exactly who is allowed to do exactly what on which systems.
 
> Tom has put in code to avoid this, but it does various checks
> before actually writing the file.  There's a small but real amount of time
> between the checks and the writing.

that would create a race condition & i fully understand that too:
again, the question is who can do what where.
 
>> but here on CHASS, that's impossible, since the system will choke
>> when Lynx asks it to allow me to write Enemy's  /tmp/dagger :
>> "You don't got permission, see:  lrwx------ ".
> Symlinks would be worthless if one user could not follow another's symlink.

not in the cases you & others have described:
User A needs only to follow his own symlink to User B's  .rc  file.

> On most Unix systems, permissions shown for the link are irrelevant:
> `ls` shows them because it always shows something in those fields,
> but the kernel ignores them.  Your permissions to a symlink are based
> on your permissions towards the pointed-to file.  However, let us suppose
> your system is different and permissions on the symlink *do* matter.
> Then there *must* be a way for the person who creates a symlink
> to change its permissions: otherwise, they would be worthless. Therefore,
> the attacker must be able to grant you permission to follow his link.

on this system, i cannot change the permission of my symlink in  /tmp :
i tried it both from  /homes/purslow  & from  /tmp  & was told:
"Cannot access  /tmp/dagger : permission denied".

if the symlink permission is observed by the system,
it will react as i described above & Enemy has no way of thwarting it;
moreover, Lynx itself can check whether  /tmp/dagger  is owned by me
& if not, whether it is world-writable: if "No & No", it should balk
(there's no race condition, since Enemy can't alter these things).
if the symlink permission is not observed by the system,
i wonder why i am denied permission to change its permissions:
it looks very much like a simple security device
to prevent the kind of abuses we are discussing
(BTW is this the `sticky bit' at work?  i need reminding what that does).

further, there appears to be no good reason for UNIX generally
not to observe symlink permissions: for the kinds of case
you & others describe, where one user uses another's  .rc  file,
the owner can make it  705 , while the other user's symlink's  700
-- matching the practice on this system -- is adequate for his needs.

subject to your further comments -- which i am finding useful -- ,
i see no reason to worry about race conditions involving  /tmp  symlinks
on any UNIX system set up like this one.

this discussion is valuable, since questions about security & races
keep coming up around Lynx proposals & changes.
we should expect system managers to do all they can to protect security:
that may mean a UNIX set-up like the one here at CHASS,
it may mean freenets should confine anonymous users to their own box.
any question raised on lynx-dev about security should give details
of how dangers can arise on a well-run system:
unfortunately in the past, that has generally not been the case.

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : address@hidden
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto