[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Re: who owns what
From: |
Philip Webb |
Subject: |
Re: lynx-dev Re: who owns what |
Date: |
Sun, 11 Oct 1998 11:21:12 -0400 (EDT) |
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
- Re: lynx-dev Re: who owns what, (continued)
- Re: lynx-dev Re: who owns what, David Combs, 1998/10/10
- Re: lynx-dev Re: who owns what, Bela Lubkin, 1998/10/11
- Re: lynx-dev Re: who owns what, Bela Lubkin, 1998/10/11
- Re: lynx-dev Re: who owns what,
Philip Webb <=
- Re: lynx-dev Re: who owns what, dickey, 1998/10/11
- Re: lynx-dev Re: who owns what, dickey, 1998/10/11
- Re: lynx-dev Re: who owns what, Bela Lubkin, 1998/10/11